Bug 395283 - Store and restore window size and location of subdialogs while editing Applicatione4xmi
Summary: Store and restore window size and location of subdialogs while editing Applic...
Status: RESOLVED FIXED
Alias: None
Product: e4
Classification: Eclipse Project
Component: Tools (show other bugs)
Version: unspecified   Edit
Hardware: All All
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords: helpwanted
Depends on:
Blocks:
 
Reported: 2012-11-28 09:01 EST by Robert Koehler CLA
Modified: 2014-06-16 09:37 EDT (History)
4 users (show)

See Also:


Attachments
Patch without persistence (12.21 KB, patch)
2012-12-01 02:46 EST, Marco Descher CLA
no flags Details | Diff
Patch including persistence as described (14.37 KB, patch)
2012-12-04 15:57 EST, Marco Descher CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Koehler CLA 2012-11-28 09:01:15 EST
It would be very nice if the size and location of these windows would be stored before closing and restored after loading. I dont want to resize the window ever and ever again.

Following dialogs are concerned:
Find Command
Find ClassURI
Find Icon
Comment 1 Lars Vogel CLA 2012-11-28 09:46:36 EST
Saving the state of the dialogs should like a nice enhancements. 

I think that is a good candidate for an external patch, please see http://www.vogella.com/articles/Eclipse4Source/article.html#e4gitrepository to learn how to get the source code.
Comment 2 Marco Descher CLA 2012-11-28 16:02:56 EST
I'll try to come up with a patch for it!
Comment 3 Lars Vogel CLA 2012-11-28 18:41:50 EST
Thanks Marco!
Comment 4 Marco Descher CLA 2012-11-30 11:32:25 EST
Hy Lars,

I did a first implementation on https://github.com/col-panic/org.eclipse.e4.tools/commit/5e0896f26479b9ca81d4142fb54cf2e10f345345

I have, however, not yet implemented the persistence part as I am not sure about one thing:

The official solution is to extend AbstractUiPlugin in the Activator and fetch the storage from there. AbstractUiPlugin however introduces the dependency to org.eclipse.ui which I was trying to avoid. I hence implemented an Activator which instantiates an element of DialogSettings to be shared among the Dialogs.

What is the correct, i.e. e4 way to proceed:

1. Introduce the dependency to org.eclipse.ui (persistence will then be taken care of)
2. Copy the respective code from AbstractUiPlugin that takes care of persistence (as has been done in org.eclipse.e4.ui.internal.workbench.swt.WorkbenchSWTActivator) 
3. Implement in a different non-Activator class or
4. store it somewhere else (the model for example)

Please give me the respective hint, such that I can finish the patch :)

thx, marco
Comment 5 Nobody - feel free to take it CLA 2012-11-30 16:41:25 EST
Your github repo is inaccessible for the moment.
Comment 6 Marco Descher CLA 2012-12-01 02:46:28 EST
Created attachment 224190 [details]
Patch without persistence
Comment 7 Marco Descher CLA 2012-12-01 02:46:46 EST
Ok, it seems to be back again! I paste the mentioned patch in case it happens again ...
Comment 8 Lars Vogel CLA 2012-12-03 13:36:50 EST
Marco, I would suggest to use directly the preference API but I'm not sure if that is the "best" way. Maybe you can clarify that in the Eclipse 4 forum or in IRC?
Comment 9 Marco Descher CLA 2012-12-04 10:25:41 EST
After an IRC chat with Paul version 2 was decided (http://echelog.com/logs/browse/eclipse-e4/1354575600). I implemented the respective solution. It is accessible on https://github.com/col-panic/org.eclipse.e4.tools/commit/4ff168a2c1186c87a12635c2cd0aca4666d35a3d (unfortunately I had some trouble with Git)

Currently all Dialogs share the same size and location that is once set. If this should be stored separately per Dialog please drop me a line I will then change the behaviour.
Comment 10 Lars Vogel CLA 2012-12-04 13:52:46 EST
Can you add a patch to the bug report?
Comment 11 Marco Descher CLA 2012-12-04 15:57:27 EST
Created attachment 224280 [details]
Patch including persistence as described

Lars, as requested!
Comment 12 Marco Descher CLA 2012-12-08 04:24:40 EST
Lars, are you okay with this patch? Thanks!
Comment 13 Lars Vogel CLA 2013-01-18 11:37:50 EST
Thanks Marco.

I tried the patch and the size of the dialog is not restored. My Test: I open the create class dialog for the Handler, close it and open it again.

Also  what is the location tracker used for?

And the solution for storing the file seems unnecessary complex to me, why don't you use the JFace preference API for that? 

See http://www.vogella.com/articles/Eclipse4Preferences/article.html
Comment 14 Marco Descher CLA 2013-03-02 13:37:15 EST
There are generally two ways to implement this:

(A)
(1) Overwrite getDialogBoundsSettings() which has to return type IDialogSettings;
If getDialogBoundsSettings() is used one has to implement a IDialogSettings capable of persisting its values in Eclipse Preferences style which is quite a lot of work.

(2) Overwrite getInitialSize() and getInitialLocation() which both return Point
and intrinsically query getDialogBoundsSettings();
If getInitial*() is used one only has to implement the getInts() within Preference to persist the respective Point elements.

(B)
Additionally it is possible to (1) overwrite all methods for each Dialog using it, or simply create a 
(2)PersistedLocationDialog that extends TitleAreaDialog which sets it once and all existing Dialogs will extend PersistedLocationDialog  instead of TitleAreaDialog.

Please tell me for which way you will accept a solution. (A1 or A2) and (B1 or B2)
Comment 15 Marco Descher CLA 2014-06-16 09:37:08 EDT
Feature realized with http://git.eclipse.org/c/e4/org.eclipse.e4.tools.git/commit/?id=0dc361ad0733d205397172baf30c164644ef46ba 

All current dialogs should be covered, please test.