From Bioinformatics.Org Wiki
Click here to go back to: Bioinformatics
bioLegato DEVELOPERS WIKI
bioLegato is a programmable graphic interface capable of handling a wide range of data types. bioLegato is:
- generic - in principle, bioLegato could be used for almost any kind of data
- object-oriented - Ideally, each instance of bioLegato will implement an object. The canvas area of the interface allows the end user to view and manipulate the data of the object. The menus represent the methods associated with that object.
- programmable - methods are not hard-coded into the bioLegato interface. Rather templates are read at run-time that create menus which, in turn, allow the user to set paramaters and run external programs
- lightweight - most functionality is through external program calls. bioLegato is "anti-bloatware"
- versatile - almost anything could be run from bioLegato, whether locally-installed programs, or web services
bioLegato takes its initial inspiration from Steven Smith's GDE interface.
PCDEdit is a graphical editor that allows the BIRCH administrator to create and modify PCD menus. It should currently be considered an experimental application.
Creation of the BioPCD language has drastically simplified the process of adding a program to a local copy of BioLegato. However, it still requires enough steps that would be daunting to most biologists. The architecture of BIRCH and BioLegato lends itself to automating almost all of these parts. This project would create a BioLegato Add-On wizard that would take as its starting point any 3rd party package that was installed on the user's system. The wizard would walk the user through the process of selecting files and directories for executables, documentation and ancillary data files (eg. scoring matrices, alternative genetic codes, lists of restriction enzyme recognition sequences). The wizard would create the appropriate environment variables and file paths, and a sample menu that suggests input file filters, program parameters, and viewers for displaying output. Finally, the wizard would let the user edit the menus and shell commands, until a working menu was achieved. The wizard would also have a mechanism for submitting the final menu as a BioLegato Add-On. The Add-On would be vetted and refined by Bit lab staff, and published to our web site, or directly incorporated into a subsequent release of BIRCH.
Need a full functioned Find built into the table. Find should tell you how many hits were found, automatically select the rows (or cells?), have an next and previous feature. Search by regular expression, ignore case... the usual stuff.
bltable is a bioLegato interface for tabular data.
bldb is a bioLegato interface for data objects. It is intended as a database client.
Migration to github
Although originally written for bioinformatics, BioLegato is potentially useful in many fields. As well, development is currently limited by lack of funding. Therefore, we would like to expand the base of developers so to expand the capabilities of BioLegato, as well as ensuring its ongoing support.
Up to now, BioLegato has been an intrinsic part of the BIRCH system, and this page was the definitive site for planning BioLegato development.
- to supersede the current BioLegato wiki with a Git site
- to make BioLegato a standalone project, separate from BIRCH
Before committing to any specific way of managing the Git repository, it will be best to create a test Git repo to try things out. Let's make mistakes and learn using a test site, and then do it right with BioLegato.
- Layout of git repo - The repo should be the central point of everything related to BioLegato development. We want to organize the main page so that everything is discoverable, with links to additional pages on specific topics. A good layout will be good for end users to find out what BioLegato is and what it can do, and for developers, not just as a repository, but also to document the fine details of the BioLegato code base, programming practices, and all other details about the code. Github appears to have a Wiki associated with a project, so this should be easy.
Examples of layouts at various Git sites:
- Sample project - a simple Java package just to try things out
- Test with NetBeans on CCL. Need to establish first how to use Git through NetBeans 8.0 on CCL.
- Test with latest NetBeans on another machine eg. flamingo. Are the problems with going back and forth between different versions of the same IDE?
- Test with other IDEs eg. Eclipse. Are there problems with different developers using different IDEs?
1. Plan layout to make things easy for end users and developers.
2. Implement main page and a few ancillary pages
3. Push the code base to Git and test checkout, modify and push
4. Start with a few easy bug fixes or simple changes to shake down the working process.