Component Library Folders and Popup Menus
The Component Library is the most used graphical component in Kepler. It is in essence the "Control Panel" for building workflows. Because of this it is important to give the user as much control over this area as possible.
To do this a mechanism for viewing components as they appear on disk is needed. This will allow users to organize their components however they want in folders while still providing the ability to index the components within the Kepler ontologies.
Popup menus allowing the user to do basic control functions like "Move, Remove (from ontology), Delete (from disk), Create New, View LSID, View Revisions, View Documentation, Open, Annotate, etc..." should be added to the components and their containers (whether the container is an ontology/concept or a folder/kar). The popup menus are displayed from AnnotatedPTree.maybeShowPopup using subclasses of the LibraryPopup class.
Updated by Shawn Bowers over 13 years ago
I think this also assumes components are fundamentally stored on disk, and if stored on disk, in a meaningful place. One could easily imagine storing actors, e.g., within an underlying DBMS, similar to the Kepler provenance framework or MyExperiment. This would make a UI based on a physical directory storage storage structure awkward and unnecessary. (A DBMS-based approach for storing Kepler items would also simplify much of the application.) Similarly, if the system is managing where components are stored on disk, exposing this information may not be that useful (e.g., if these are within the .kepler folder, or as in pre-installed kars).
Updated by Timothy McPhillips over 13 years ago
Addressing Christopher's comment, I think what this makes this entry "bug-ish" is that the Component Library looks like a nested folder hierarchy. In many other software products the user can reorganize objects displayed in such a widget, rename folders, add new folders, etc, so it "feels" like one should be able to do this in Kepler as well. The components in our Library even can be dragged around (because they are meant to be dragged onto the canvas), but you cannot drop a component in a different "folder".
I would love to be able to quickly organize components the way I like as Aaron suggests.
Updated by Aaron Aaron over 13 years ago
Shawn, Kepler's library is now built from KAR files stored on disk in folders referred to as "Local Repositories". This was specifically done to get away from storing things in the RDBMS as was done in Kepler 1.0. See bug 3898. By storing things in an RDBMS (and nowhere else) the complexity is greatly increased because of the need to transition all that data to new versions of the software. It also becomes much more of a black box to the user as to what is going on and has an impact on transferring data between Kepler instances. It is also awkward for many different modules to contribute to an RDBMS structure intelligently. Using KAR files on disk as the main data store for user generated content and using the RDBMS as purely an indexing mechanism for java serialized copies of the KAR contents (to increase performance) is what we should be shooting for in the 2.0 release of the core modules (and really that's where we're at now, excepting some outstanding issues).
Updated by Matt Jones over 13 years ago
Kepler used to have at least some of these functions, such as the ability to delete a component from the Library. See bug # 4047 for an example of delete functionality that used to work. Maybe some of the earlier code can be reincarnated to fix these regression bugs.
Updated by Aaron Aaron about 13 years ago
Subclasses of the LibraryPopup class can now be used to add right click menu functionality to items in the component library in concert with AnnotatedPTree.maybeShowPopup().
Closing this bug, new bugs can be opened for more specific issues related to this system.