Community
Participate
Working Groups
I have an editor and a lightweight editor input. I wanted to add the MRU that eclipse supplies for editor inputs. I also wanted that the editor input will be persistable, so I would be able to get back to my last inputs between sessions. I made my editor input persistable, but to my suprise, I couldn't disable the auto reopening of the editor between sessions (I only wanted the MRU). My editor takes a lot of time to load itself from the input, because it has to calculate a lot of things, so auto reopen is not an option. I want an interface, something like IPersistableEditorInput that will extends IPersistableElement, and will contain a boolean openOnStartup() method. The result of calling that method will be saved in the memento, so next time I will open eclipse, the input will be in the MRU but won't be opened automatically. (I think that a general "Restore Editor state on startup" preference won't fit my needs, because sometimes I want a certain editor input to open on startup, and a different one not to open)
I forgot to say that it would be more symmetrical if the editor itself will also have an openOnStartup() method - So the editor will open on startup with its input - if it, itself, will declare that it opens on startup, and its input will also declare that it opens on startup (An "and" expression). * I don't really need that symmetrical behaviour - but I think it may be useful to others.
(In reply to comment #0) > My editor takes a lot of time to load itself from the input, because it has to > calculate a lot of things, so auto reopen is not an option. Why don't you do the bulk of the work in the background?
(In reply to comment #2) > (In reply to comment #0) > > My editor takes a lot of time to load itself from the input, because it has to > > calculate a lot of things, so auto reopen is not an option. > Why don't you do the bulk of the work in the background? A. I think that is understandable that an editor needs a lot of time to calculate things from the input. Besides, after the first time it calculates the data for that specific input, the data is cached (Calculate for me is performing an sql query and connect the returned entries - in a tree hierarchy that I build. I save the tree structure in a cache (with soft links), so trying to load the same input twice will result using that cache). Of course, I can do it smarter - like an asynchronious loading process, but I prefer not to - It will just make the code more complicated, and the long loading process longer. And another thing, the first time I open the program, nothing is loaded - so obviously there is no cache, and opening the editor will take time. B. All of the above, doesn't change the fact, that my request is logical. And even if it the editor doesn't take a lot of time to load, I still think that some editor \ editor inputs should not be opened on startup, and some should, with no consideration to the MRU. C. Most of the time my users don't want to access the old data (After all, they already saw it, and performed changes on it, so it's less relevant for them. They want to see the new data that has arrived). So opening the old data automatically, just because the editor was opened before, will just annoy them, on the other hand, they want the ability, to see what they worked on the last time, they used my app, and also to reopen it, if needed. D. I don't know if I want all my editors not to reopen on startup. Maybe I will want this in the future - so disabling the reopen for all editor is problematic.
I don't want to make a change like this because it makes the behaviour less consistent and predictable for end users. For 4.0, I would like to separate mechanism (what are the things the platform can do) and policy (which behaviour do we enforce at the application level), so that features like this can be implemented for RCP applications without affecting other applications like the IDE where we want consistency and predictability. Marking 4.0 as a good example for something where we should separate mechanism and policy.
(In reply to comment #4) > I don't want to make a change like this because it makes the behaviour less > consistent and predictable for end users. > For 4.0, I would like to separate mechanism (what are the things the platform > can do) and policy (which behaviour do we enforce at the application level), so > that features like this can be implemented for RCP applications without > affecting other applications like the IDE where we want consistency and > predictability. Marking 4.0 as a good example for something where we should > separate mechanism and policy. I can see your point. To my users it will seem natural, but in eclipse - it will really look odd. The problem is that the editor history and the MRU are not built so I can extend them easily... Maybe adding util methods, to make it easier for me to write the appropriate code, will be enough (With a code example for how to use it). Also changing the editor history to something like a service so I will be able to create my own service to decide what to save in the memento that save the input, and on the way that it will affect the autoreopn - using the existing code.
Remy is now responsible for watching the [EditorMgmt] component area.
Removing outdated target milestone.
