VICI: A Software Development Project - Page 8
FedoraForum.org - Fedora Support Forums and Community
Page 8 of 9 FirstFirst ... 6 7 8 9 LastLast
Results 106 to 120 of 127
  1. #106
    Join Date
    Oct 2010
    Location
    Canberra
    Posts
    3,016

    Re: VICI: A Software Development Project

    Common Code and Testing

    Up to now the VICI project has consisted of a collection of semi-independent sub-projects. It has a common library for low level infrastructure (such as reading XML files) and others for overall configuration and the interfaces between the projects, but mostly each sub-project has been developed relatively independently.

    An inevitable side effect of this approach is that some things will be duplicated. For example the "About" dialog needs to be provided by each GUI program. If each sub-project develops their own version the overall appearance of VICI will appear confused.

    One approach to this is to provide a strict set of design guidelines so that each instance will appear similar. Another approach is to provide a common library containing various bits and pieces that will be used in multiple sub-projects. The common library has the obvious advantages of less code duplication (and hence less maintenance), but it does introduce a dependency between the sub-projects.

    I have decided to add a small common GUI library. It has an "About" dialog, a small helper class that makes editing the entries in Qt's list widgets a lot less stupid, and wrappers for the main window and dialog classes that provide a hook for the GUI Test Harness to find the widgets.

    Testing ... Oops

    Using the new GUI Test Harness to get it to interact with GUI programs seems to be working as planned. However, the whole point is to manoeuvre the GUI program into a state so that the test harness can check the state of the program's internal objects, but I seem to have overlooked the mechanism for the test case objects to actually find the program objects.

    My initial idea was to use something similar to the way the asynchronous testing works - a pointer to a function was to be used to register the objects that we want to test. This pointer would be initialised to an empty function during normal operations and an actual function for registering the object during testing. The function pointer would be called during the constructors for the application objects.

    Unfortunately, this doesn't work since the test harness may be in a plug-in that is not loaded until all the application objects have been initialised. The function pointer would always be pointing to the empty function when it was needed.

    User error. Please replace user and try again

  2. #107
    Join Date
    Oct 2010
    Location
    Canberra
    Posts
    3,016

    Re: VICI: A Software Development Project

    Object Discovery

    As mentioned in the previous post the test case objects need some means of getting a reference to the objects that they are supposed to test. To support this I have added a discovery facility to the infrastructure library.

    The requirements are:
    • Objects get to determine if they can be discovered. This means we can minimise the performance penalty by only handling a few important objects.
    • Objects are to be found by class name. A vector of pointers to objects of the class is returned. (Usually it will just be one entry, but this caters for other uses.)
    • We don't want to get pointers to objects that have been deleted.
    • It should work even if there is nothing asking for the objects. This is necessary since the test cases may be in a plug-in that may or may not be loaded.
    • The discoverable objects should require a bare minimum of extra code.


    The discovery code has the following interface
    Code:
    struct DiscoverPointer
    {
    	void * addr;
    	DiscoverPointer() : addr(nullptr) {}
    	DiscoverPointer(void *a) : addr(a) {}
    };
    
    typedef std::shared_ptr< DiscoverPointer > DiscoverSharedPointer;
    typedef std::weak_ptr< DiscoverPointer > DiscoverWeakPointer;
    
    // A mixin class that makes its owner discoverable
    class Discoverable
    {
    protected:
    	DiscoverSharedPointer discover;
    };
    
    // the manager that keeps the list of discoverable objects
    // and is responsible for supplying a list of pointers given a class name
    
    class DiscoveryMgr
    {
    private:
    	std::map<std::string, std::vector<DiscoverWeakPointer> > objects;
    	DiscoveryMgr() {}
    public:
    	static DiscoveryMgr & instance();
    
    	void save(const char *prettyName, DiscoverSharedPointer);
    	void fetch(csr name, std::vector<void *> & results);
    };
    
    // This macro should be placed at the start of the constructor.
    #define DISCOVERABLE \
    	VICI::cfi::DiscoveryMgr::instance().save( __PRETTY_FUNCTION__, \
    			(discover.reset( new VICI::cfi::DiscoverPointer( this )), discover) );
    To make a class discoverable it inherits from Discoverable, and includes the DISCOVERABLE macro in its constructor.

    The save function does a bit editing on the __PRETTY_FUNCTION__ to get the class name and stores the discover structure in a map.

    The fetch function finds the class name and checks to ensure that the weak shared pointer is still valid.

    To get a reference to a discoverable object the test case does the following:
    Code:
    	vector< void * > objs;
    	DiscoveryMgr::instance().fetch("VICI::Syntax::SyntaxImpl", objs);
    	if ( objs.size() > 0)
    	{
    		syntax = static_cast<Syntax::SyntaxImpl *>(objs[0]);
    	}
    While this works, and enables work to continue on the testing, I will probably revisit it later to add a template version of DiscoverPointer so that it is a bit more type safe.

    User error. Please replace user and try again

  3. #108
    Join Date
    Oct 2010
    Location
    Canberra
    Posts
    3,016

    Re: VICI: A Software Development Project

    Phase 8 Completed

    I have just uploaded vici-0.8.560 to SourceForge https://sourceforge.net/projects/ocratato-vici/

    This release provides a more standard build process and a better test harness for GUI programs.

    The next phase of development will provide the interface for entering commands and their parameters. Hopefully it won't take too long to develop.

    User error. Please replace user and try again

  4. #109
    Join Date
    Oct 2010
    Location
    Canberra
    Posts
    3,016

    Re: VICI: A Software Development Project

    Configuration

    Usually I write these posts after I have implemented something, but this time it is more of a planning session.

    Some background
    VICI uses an XML file to hold various bit of configuration data. A lot of those data items are the paths to things like data files or plug-in libraries. The location of those data and plug-in files changes depending on what stage we are considering. There are the following stages:

    1. The development project - this is where the code is written and unit tests are performed.
    2. The top project - this is for building and testing the entire suite of programs.
    3. Creating a distribution - the "make distcheck" command creates and tests the distribution.
    4. Checking the distribution - this is when the distribution has been installed into a test area and has been built but not installed. This is a "make check" that is done between "make" and "make install".
    5. Checking the installed distribution - this is a "make check" done after installation.
    6. The final stage - this is where the installed programs are used (or tested) without relying on the source, such as when it is installed from a pre-built RPM.


    There are two ways that the system can handle these various paths. The simplest is to have alternate configuration files that are used for each stage. However, the configuration library (that reads and interprets the configuration file) is able to handle having multiple alternative paths which it checks in turn until it finds one. For example the configuration for a plug-in:
    Code:
    		<PlugIn prog='adminTest'>
    			<name>admintest</name>
    			<mode>autorun</mode>
    			<path>$VICI/src/top/build/admin/TestProgram/.libs/libadmintest.so</path>
    			<path>$VICI/lib/vici/plugin/libadmintest.so</path>
    			<path>$VICI/src/admin/build/TestProgram/.libs/libadmintest.so</path>
    		</PlugIn>
    When attempting to load this plug-in it checks each path until it finds one.

    The configuration library searches for the configuration file using various techniques. It can use a command line parameter, an environment variable, or search for particular files in the current directory, the user's home directory, or others. The first one found is used.

    Currently the search path is
    Code:
    		"PECHD:"
    		"-i:VICI_CONF:"
    		"vici.xml:"
    		".local/share/vici/vici.xml:"
    		"$VICI/src/top/vici.xml:"
    		"$VICI/share/vici/vici.xml:"
    		"$VICI/vici.xml";
    The first string is the key - in this case it means that the following entries are a command line parameter, -i, an environment variable, VICI_CONF, the file ./vici.xml, the file ~/.local/share/vici/vici.xml, and the remainder are direct paths.

    The Problem
    What is the optimum set of configuration files?

    Each development project should have its own configuration file. This would allow the project to manage its own configuration and testing without disturbing other projects. Eclipse can be set up to provide parameters to the test programs so that should be used to ensure the local one is found. However, we want to ensure that configuration options are not overlooked in the full suite build so the "make check" tests should use an environment variable that points to top/vici-dev.xml which will be the config file for the top project.

    The builds and tests in the top project will use top/vici-dev.xml via VICI_CONF. This version of the configuration file will point to files that have not been installed.

    There will be a second configuration file, top/vici-test.xml. This version will point to files that have been installed and include all the entries necessary for testing. This will also be accessed using VICI_CONF

    The final version, vici.xml, will be used by the programs once they are installed. The support for testing will be removed, or commented out. This will be found using the default location in share/vici.

    User error. Please replace user and try again

  5. #110
    Join Date
    Oct 2010
    Location
    Canberra
    Posts
    3,016

    Re: VICI: A Software Development Project

    For those that have been following this thread, you may have noticed its gone a bit quiet lately. I am taking a short break as I have been distracted by another interesting problem.

    I noticed that there are some interesting comments on SlashDot concerning visual programming languages: https://ask.slashdot.org/story/17/06...ng-flow-charts

    User error. Please replace user and try again

  6. #111
    Join Date
    Oct 2010
    Location
    Canberra
    Posts
    3,016

    Re: VICI: A Software Development Project

    I am trying to ramp up some enthusiasm for the next bit of VICI development. Its hard because its a bit hot here, which means less than optimal sleeping, which makes it difficult to get one's thoughts straight.

    However, I would like to thank those that mentioned QTerminal recently. After a bit of digging I found libqtermwidget.
    The next bit of development includes a panel for displaying man pages. In my prototype I embedded the xterm program for this, but I am concerned that future moves to Wayland will leave xterm even less supported than it is now. Finding a Qt based widget that does a terminal emulation will avoid that problem.
    So, thanks aurquiel and milhan.

  7. #112
    Join Date
    Oct 2010
    Location
    Canberra
    Posts
    3,016

    Re: VICI: A Software Development Project

    One of the features of VICI is that when you are setting up a command it will show you the available help text. For most commands this comes in the form of man pages, or info pages. My problem is how to present this to the user ?

    Ideally I would like to display the info in a panel on the application's command entry tab. The alternative is a separate pop-up window, but that will probably obscure the main window which would be annoying.

    My first idea was to convert the pages to HTML and let Qt's excellent HTML renderer do its thing.
    Converting a man page to HTML is relatively straightforward - groff has a HTML output so they can be generated as required.
    Converting info pages is more complex as they come as a set of linked nodes which should be converted into linked HTML pages. Using the source files that are used to generate the info files would probably be the best, but they won't be installed on the users' machines.

    So my next idea was to simply run the man or info command in a terminal. This would remove the need to do a conversion as the man and info programs would do the appropriate rendering, and in the case of info, it would also allow the user to do the navigation.
    Some research showed that an xterm can be embedded in a QtWidget so this looked promising - I could have the xterm display the command and be a part of the command entry tab.

    I have just implemented the embedded xterm solution, and it appears to work quite well.
    However I have discovered that this will all change between Qt4 (my development environment) and Qt5. The process for embedding is quite different. There is also the issue of xterm. Will it continue to be available as Wayland takes over from X ?

    For this reason I was quite happy to find QTermWidget as I should be able to just run the commands in a widget without having to worry about embedding. Unfortunately it turned out to be not quite as good as I had hoped. There are two versions, one for Qt4 and one for Qt5, so the build process will become more complex to allow for that. When I tried the Qt4 version it complained about not being fully functional - no idea why, but it seemed to be having trouble finding bold fonts.

    More seriously, the QTermWidget needs to start processes and it does this with Qt's QProcess object. Sadly this collides with my process library that is used for the rest of VICI - they both want to catch signals. My library can cope with having another signal catcher, but I am not sure about Qt's. This could lead to a race condition as to which signal handler get installed first.

    So I am left with multiple options, all of which are complicated, just to show some help text.
    This really should not be this difficult !

  8. #113
    Join Date
    Oct 2010
    Location
    Canberra
    Posts
    3,016

    Re: VICI: A Software Development Project

    OK, I am now annoyed.

    My Qt4 version of VICI uses something called QX11EmbedContainer.
    To run an xterm as a widget in the application you just have to start the xterm with a parameter referring to the window id of the container - easy.

    The Qt5 version has removed QX11EmbedContainer. They did not even see fit to deprecate it - they just dropped it like a hot rock.

    There is something that allows you to create a container for another application, but you have to pass it a QWindow object that, in turn, requires the window id of the xterm. There is no sensible way of programmatically getting the window id of an xterm,and even if I did it would be of no use since the application will want to run many instances of the xterm in that window (sequentially, of course).

    User error. Please replace user and try again

  9. #114
    Join Date
    Oct 2010
    Location
    Canberra
    Posts
    3,016

    Re: VICI: A Software Development Project

    Looking to the Future

    Increment #9
    I have just put the finishing touches to the module that assists the user in entering a command and its options. It uses HTML to display man pages and info pages. This should be more future proof than the version that ran the commands in an xterm.
    The next bit of work involves integrating the command and search modules into the editor.
    After that there is a fair amount of work providing the user manual and on-line help.

    Increment #10
    The next phase will be the ability to run and inspect scripts from the editor. I am looking forward to this - it should be quite interesting.
    One of the features of graphical programming languages that is often mentioned is the ability to see what is going on. Adding this to VICI is therefore an important part of the program.

    Increment #11
    This phase integrates VICI into the desktop. It will allow the user to install their scripts so that they can be run from the desktop menu or set them to run at a specific time.
    It will also involve an update to the file format. Currently it is just XML, but the idea is to put the XML into a container in the file and add the ability to sign or encrypt the file. This is to make it a bit harder to just download a VICI script from the net and run it without knowing what it really does.

    The subsequent development work is a bit less well defined:

    Manifolds
    One of the problems with programs like VICI is that it doesn't provide anything which advanced users or developers need - they will just run a bash script from a terminal. To make it more attractive I going to build on VICI's multi-threading capability to provide some features that are hard to do in bash. The manifold will be a component that can split or merge threads of control. Hopefully this might attract some users that are prepared to add some enhancements.

    Languages
    So far VICI is pretty much an ASCII only program. That is hardly acceptable in this world, so a phase of development will attempt to remedy that.

    Errors and Messages
    I am not very happy with they way errors and other messages are handled.

    User error. Please replace user and try again

  10. #115
    Join Date
    Oct 2010
    Location
    Canberra
    Posts
    3,016

    Re: VICI: A Software Development Project

    Phase 9 Completed

    I have just uploaded vici-0.9.651 to SourceForge https://sourceforge.net/projects/ocratato-vici/

    This release integrates the search and command panels into the editor program:
    Click image for larger version. 

Name:	editor.png 
Views:	8 
Size:	46.7 KB 
ID:	29524 Click image for larger version. 

Name:	Screenshot from 2018-04-11 17-49-48.png 
Views:	3 
Size:	71.3 KB 
ID:	29526 Click image for larger version. 

Name:	Screenshot from 2018-04-11 18-04-09.png 
Views:	8 
Size:	81.7 KB 
ID:	29525

    User error. Please replace user and try again

  11. #116
    Join Date
    Oct 2010
    Location
    Canberra
    Posts
    3,016

    Re: VICI: A Software Development Project

    Phase 10 Completed

    I have just uploaded the latest version:
    https://sourceforge.net/projects/ocratato-vici/

    The major change was to include the run-time program into the editor so you can tests your scripts without having to start a separate program. It also includes some rudimentary support for debugging and monitoring a running script.

    The run-time can now display script variables, and you can set them to pass values into the script.

    User error. Please replace user and try again

  12. #117
    Join Date
    Oct 2010
    Location
    Canberra
    Posts
    3,016

    Re: VICI: A Software Development Project

    Sadly things are not going well.
    The feedback I am getting is that the build is having some serious problems locating the Qt libraries.

    As a result I am rewriting the configure script responsible for Qt.

    I am going to make better use of the package configuration files so these problems will, hopefully, be properly solved.

    However there is an interesting problem - there is no way of telling which version of Qt is installed other than by trial and error. Most advice on the web says to use "qmake --version" but that that just gives me the version of qmake (1.07a) that was apparently built with Qt 3.3.8b. The only way to really find out is to use the QT_VERSION symbol, but that is in the QtCore library, which can be either libQtCore.so (for Qt4) or libQt5Core.so (for Qt5) - in other words to find out the version I have to know which version to use !!!

    The package config files don't help either - its either QtCore.pc or Qt5Core.pc.

    Further complicating things is that on my system I have both Qt4 and Qt5 installed and I need to be able to select which to use so I can test VICI.

    Code:
    # Find the package config file
    AC_DEFUN_ONCE([BR_QT_PKG_CFG],
    [
    AC_MSG_CHECKING(Qt Package Config)
    
    AC_ARG_WITH([qt-pkg],
    	AS_HELP_STRING([--with-qt-pkg=package],
    		[to specify the Qt package config directory.]),
    	[QTPACKDIR="$withval"],
    	[QTPACKDIR=""])
    
    if PKG_CONFIG_PATH=$QTPACKDIR pkg-config --modversion Qt5Core &> /dev/null
    then
    QTCORE=Qt5Core
    elif PKG_CONFIG_PATH=$QTPACKDIR pkg-config --modversion QtCore &> /dev/null
    then
    QTCORE=QtCore
    else
    	AC_MSG_ERROR([Could not find config package for Qt])
    fi
    AC_MSG_RESULT([yes])
    ])
    This gives me enough info to then build a tiny program for getting the actual version number from QT_VERSION symbol, and from there its just a matter of extracting the values from the package config files and running some tests to ensure the user's system is set up properly.

    User error. Please replace user and try again

  13. #118
    Join Date
    Oct 2006
    Location
    CN99CF Agassiz BC Canada
    Posts
    401

    Re: VICI: A Software Development Project

    What about querying /etc/alternatives/qtchooser-default? This link should be pointed to the appropriate libraries.
    -----
    f26 x86_64 Acer Predator G5910 Quad core Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz

  14. #119
    Join Date
    Oct 2010
    Location
    Canberra
    Posts
    3,016

    Re: VICI: A Software Development Project

    Quote Originally Posted by jims
    What about querying /etc/alternatives/qtchooser-default? This link should be pointed to the appropriate libraries.
    Thanks for the thought.
    Mine points to a non-existent file.
    I don't have qtchooser installed (only heard about it recently) so I don't think it would be a reliable way to discover what was installed on other people's systems.

    User error. Please replace user and try again

  15. #120
    Join Date
    Oct 2010
    Location
    Canberra
    Posts
    3,016

    Re: VICI: A Software Development Project

    Release 0.10.681 Published

    I have just uploaded a new version which uses the technique described above for finding the Qt files.
    It turned out to be a bit more complex than it should have since the config files don't seem to include all the necessary flags, so I had to go back and add them to each of the 11 subprojects.

    Then we get to SourceForge where it seems to be a bit of a lottery if their version control system will work - today its not working.
    Then it gave me an internal error on the first attempt to upload the new version.
    They used to be good, fast and reliable, but its been going downhill rather quickly recently.

    User error. Please replace user and try again

Page 8 of 9 FirstFirst ... 6 7 8 9 LastLast

Similar Threads

  1. Web Development Software
    By Pepperonie in forum Using Fedora
    Replies: 2
    Last Post: 5th May 2007, 10:56 PM
  2. Development software for Linux
    By jo3 in forum Using Fedora
    Replies: 9
    Last Post: 15th June 2006, 03:28 PM
  3. Software Development
    By handshakeit in forum Using Fedora
    Replies: 0
    Last Post: 5th October 2005, 08:40 AM

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •