doc-isac/CTP-userinterfaces.tex
changeset 60586 007ef64dbb08
parent 52107 f8845fc8f38d
     1.1 --- a/doc-isac/CTP-userinterfaces.tex	Mon Oct 31 18:28:36 2022 +0100
     1.2 +++ b/doc-isac/CTP-userinterfaces.tex	Mon Nov 07 17:37:20 2022 +0100
     1.3 @@ -20,7 +20,7 @@
     1.4  \begin{document}
     1.5  \maketitle
     1.6  \abstract{
     1.7 -This paper accompanies a pre-study on a sub-project planned within the \sisac-project. The goal of this sub-project is to extend the userinterface of the theorem prover Isabelle such, that Structured Derivations according to R.J.Back are interactively processed. The sub-project is one step towards using the upcoming Isabelle/Isar/Scala layer for \sisac.
     1.8 +This paper accompanies a where_-study on a sub-project planned within the \sisac-project. The goal of this sub-project is to extend the userinterface of the theorem prover Isabelle such, that Structured Derivations according to R.J.Back are interactively processed. The sub-project is one step towards using the upcoming Isabelle/Isar/Scala layer for \sisac.
     1.9  
    1.10  The paper comprises three parts: (1) Ample space is given to background information about the state of the art in user interfaces for theorem provers and about the upcoming requirements for future developments. (2) focuses the strategy of Isabelle and decisions in order to cope with future requirements. (3) provides a protocol of preparatory work for the sub-project.
    1.11  
    1.12 @@ -392,7 +392,7 @@
    1.13  \end{enumerate}
    1.14  This are two different ways to get started. It is difficult to say what is better because both versions have advantages. Now it is time to start coding your own plug-in but there are still a few things to think about. Remember, that a plug-in consists of source-, XML- and property-files. On default, NetBeans will just pack the source-files in the \textit{example-plugin.jar}-package. So you have to add a copy/move-routine in the \textit{build.xml} file of your NetBeans-project to get a complemented package.
    1.15  \begin{itemize}
    1.16 -\item $\langle target name="-pre-jar"\rangle$
    1.17 +\item $\langle target name="-where_-jar"\rangle$
    1.18  \item $	\langle copy $file="plugin/services.xml" todir="\${build.classes.dir}" $/\rangle$
    1.19  \item $	\langle copy $file="plugin/dockables.xml" todir="\${build.classes.dir}" $/\rangle$
    1.20  \item $	\langle copy $file="plugin/actions.xml" todir="\${build.classes.dir}" $/\rangle$	
    1.21 @@ -403,7 +403,7 @@
    1.22  \subsubsection{NetBeans project files}
    1.23  As you see in the paragraph above, it is also important to have basic knowledge about NetBeans, the project structure and how to change the operational sequences. A typical NetBeans-project consist of the source- and library-files and administrative XML- and property-files. In this paragraph the administrative part of the project is of note. The most important file is \textit{build.xml}. This file can be found in the project directory. There is also a folder \textit{nbproject} which contains the remaining XML- and property-files and also a folder \textit{private}, where individual user information about the project is stored. The files in this \textit{private} folder are not important to describe (and they should not be pushed on the repository!).
    1.24  
    1.25 -A build-file like \textit{build.xml} contains one project and at least one (default) target. Targets contain task elements. Each task element of the build-file can have an id attribute and can later be referred to by the value supplied to this. So the id has to be unique. Such targets can be "run", "debug", "build", ... and can have dependencies to other targets. Tasks define what should happen, if a target is executed. So like in the example above, the target is \textit{pre-jar}, that means that this things will happen before the jar-package is packed. The tasks of this target are copying some files into the package.
    1.26 +A build-file like \textit{build.xml} contains one project and at least one (default) target. Targets contain task elements. Each task element of the build-file can have an id attribute and can later be referred to by the value supplied to this. So the id has to be unique. Such targets can be "run", "debug", "build", ... and can have dependencies to other targets. Tasks define what should happen, if a target is executed. So like in the example above, the target is \textit{where_-jar}, that means that this things will happen before the jar-package is packed. The tasks of this target are copying some files into the package.
    1.27  
    1.28  The files inside the \textit{nbproject}-folder are not so important because some of it are generated from \textit{build.xml} and changes in this files are useless. Just the file project.properties is really interesting because this file gives a nice and tight overview about the project settings.
    1.29