Kepler

Last I knew, the "last used directory" was remembered (unless you restart Kepler). It's very convenient [for me].

Hi Ben:

Yes, you're right: remembering the last used directory (even if only within a session) is convenient!

If we added the N (e.g. N=5 or even N=3) most recently used to the menu, then this would of course "survive" a Kepler restart (at least that's the whole point of "recent files").

I think a list of MRU workflows in the File menu is important to have for the 2.0 release.

A menu for recently opened files was added to Ptolemy some time ago.

I've updated Kepler's menu mapper so that the menu entries can be accessed in Kepler. I also added the entry to uiMenuMappings_en_US.xml, but left it commented out since it only partially works:

1. The list is only updated when opening files. If I create a new model and save it, it does not appear. (this is an issue in the Ptolemy code).

2. The list is not updated in every open window. (this is also related to the Ptolemy code).

3. The list is not update for KAR files.

#3 is probably the most important for Kepler now that KARs are the default format. However, you can still enable the list by uncommenting the entry in uiMenuMappings_en_US.xml.

The file history.txt is no longer ever updated by Kepler. At r26484 the open dialogs were merged, and OpenArchiveAction got an _open method that's very similar to Top._open. However it lacks the call to _updateHistory that Top's version has.

Note also that Top refers to the submenu Recent Files by name in the code, so you cannot simply rename the menu item ala the usual name/value pair in uiMenuMappings_en_US.xml (it looks like Open Recent is what OS X apps typically use, and Recent Files is what Windows apps typically use).

I fixed the issues in comment 4 for both Vergil and Kepler:

1. it's now updated for both opens and saves.

2. all history menus in open windows are updated, not just the newest one.

3. it's updated for KAR files (Kepler only).

After updating sources, you will need to remove $HOME/KeplerData/modules/gui/configuration/uiMenuMappings_en_US.xml (if it exists) before the history menu will appear. The new features for this bug have been completed; I'll close after more testing.

Awesome!
Seems to only show 4 though, in my initial test on linux.
I like seeing a lot of recent files; I vote for increasing to 7 or 10. Anyone else have an opinion?

Sure, increasing it to 7 would be good.
It would be nice if there was a way to show even more files, but that seems
like work.

I've gotten this error twice when trying to open a file from the File=>Recent Files menu. I don't know the replication procedure yet. It seems to happen when I'm trying to open a workflow that does exist on disk, and that was recently opened and closed:

Impossible to read history. Please check that file exists and is not in use !
No associated Tableau! Can't open a file.

java.lang.Exception: No associated Tableau! Can't open a file.
at ptolemy.actor.gui.TableauFrame._read(TableauFrame.java:1034)
at org.kepler.gui.KeplerGraphFrame._read(KeplerGraphFrame.java:1518)
at ptolemy.gui.Top$HistoryMenuListener.actionPerformed(Top.java:1961)
at org.kepler.gui.MenuMapper$1.actionPerformed(MenuMapper.java:397)
at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1995)
at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2318)
at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:387)
at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:242)
at javax.swing.AbstractButton.doClick(AbstractButton.java:357)
at javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:809)
at javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:850)
at java.awt.Component.processMouseEvent(Component.java:6288)
at javax.swing.JComponent.processMouseEvent(JComponent.java:3267)
at java.awt.Component.processEvent(Component.java:6053)
at java.awt.Container.processEvent(Container.java:2041)
at java.awt.Component.dispatchEventImpl(Component.java:4651)
at java.awt.Container.dispatchEventImpl(Container.java:2099)
at java.awt.Component.dispatchEvent(Component.java:4481)
at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4577)
at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4238)
at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4168)
at java.awt.Container.dispatchEventImpl(Container.java:2085)
at java.awt.Window.dispatchEventImpl(Window.java:2478)
at java.awt.Component.dispatchEvent(Component.java:4481)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:643)
at java.awt.EventQueue.access$000(EventQueue.java:84)
at java.awt.EventQueue$1.run(EventQueue.java:602)
at java.awt.EventQueue$1.run(EventQueue.java:600)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:87)
at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:98)
at java.awt.EventQueue$2.run(EventQueue.java:616)
at java.awt.EventQueue$2.run(EventQueue.java:614)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:87)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:613)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)

I've increased the list size to 7 and improved the error handling when files don't exist.

Christopher wrote:

Sure, increasing it to 7 would be good.
It would be nice if there was a way to show even more files, but that seems
like work.

Do you mean more types of files? or longer list size?

Dan wrote:

Christopher wrote:

Sure, increasing it to 7 would be good.
It would be nice if there was a way to show even more files, but that seems
like work.

Do you mean more types of files? or longer list size?

I mean like having a menu choice that says "Show even more files",
kind of like what some tools have.

I don't think this is necessary though.

The history menu uses Configuration.openModel() to open files. If the file is a KAR, but cannot be opened, then the KAR is opened with TextEffigy. See bug 5280 comment 1.

Decided to change it to be 10 instead of 5.

I increased the list size to 10 and updated TextEffigy and ExpressionShellEffigy to not open KARs.

Original Bugzilla ID was 4068