Kepler

I think this is a feature request, not a bug.
A bug is behavior of a currently implemented feature that does not work
as expected.
This proposed feature looks interesting, but I question whether it should
be done before 2.0.0

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).

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.

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).

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.

Look, it's different now, if a delete function worked when everything was stored in the database then it's probably not going to work now.

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.

Original Bugzilla ID was 4320