إحنا إضحك علينا يا رجالة

و الله ده حصل يا رجالة .... إحنا بقالنا 56 سنة مضحوك علينا  .... و أنا كده مضايق .... منه لله بقا توفيق الحكيم

Managing the Layout of the Workbench in Eclipse RCP

Setting the layout of the Workbench in any Eclipse RCP application can be a daunting task if your application needs any control over the placement of views and editor area that is not directly exposed through the RCP interface.

But some techniques can be used to provide (relatively) more control over the layout by managing the perspective settings and hinting the view size.

In the perspective

In the class implementing IPerspectiveFactory (the class that implements the Perspective to the org.eclipse.ui.perspective extension point), you can:

Enable or disable the Editor area, if you are to design an Editor, this setting should be kept to true

layout.setEditorAreaVisible(true);

You can also use the Fixed Layout option, this removes he ability o maximize and minimize views and the editor area (through the min/max buttons and through the double clicking on the view title.

This keeps the ability to resize single views (as if they are included in Resize composites, but without the ability to reorder the views, or stack them or minimize them as fast views)

layout.setFixed(true);

The order of the views to be added decides who gets the full layout to take part of it and what views get the remaining of the layout to take further parts of it

Views

Views can be standard views, stand-alone views or fast views:

A stand-alone view is a special kind of view that cannot stack other views with it, and can optionally enable/disable the title bar

layout.addStandaloneView(MyOwnView.ID, true, IPageLayout.TOP, 1f, editorArea);

Standard view is a simple view in the Workbench that can be docked, stacked, minimized, maximized or detached inside the Workbench window

layout.addView(SampleView.ID, IPageLayout.LEFT, 0.5f, editorArea);

Fast views are shortcuts to the actual views put in the toolbar at the bottom of the Workbench window and shares the status bar if visible

layout.addFastView(SampleView.ID, IPageLayout.DEFAULT_VIEW_RATIO);

Views and hinting its size (in Eclipse 3.4 and upwards)

By implementing the ISizeProvider Interface in the ViewPart class that is creating the view, you can get the view to set its minimum and maximum size, given that the view doesn't get docked into other views (which can be easily made by using stand-alone views), the simplest implementation would be:

@Override public int computePreferredSize(boolean width,
int availableParallel, int availablePerpendicular, int preferredResult) {
return width ? 100 : 110;
}
@Override public int getSizeFlags(boolean width) {
return (SWT.MIN | SWT.MAX);
}

Change has come

A new day has come, not only to america, but to the whole world .... I hope he will be a real world leader, and not like his predecessor.
The exit polls shows that a new wave of supporters are going after America's and the World's future.

Branching and Merging in Subversion

Subversion (and Subclipse as my current UI to it) has a somehow tricky branching and merging technique, I've tried it for some time and the only way I managed to do it is by:

1. The main trunk is branched using Team -> Branch/Tag (this initiates a Commit which is recorded in context to the branch, not in the main trunk; you can get its revision number by showing the history of the project linking to the branch or the main repository in the SVN Repositories view, but not the project linking to the trunk)


2. You can select to switch to the branch in the same project, or keep this project linked to the trunk and checkout another project linking to the new branch
   
3. Edits can be done independently from both the trunk and the branch where the commits don't conflict (as they are in fact different files)
   
4. When you need to incorporate a change that has been done in the trunk but not in the branch (like a bug fix or to keep the branch up with the trunk), the Merge command can be used:
   
   • Select the project containing the branch
     
   • Select Team -> Merge
     
   • In the "From" group, press the select button beside the revision number
     
   • In the available revisions select the revision you branched at (the Commit of the branching order)
     
   • In the "From" group, press the Select button beside the URL text box
     
   • Select the trunk folder
     
   • In the "To" group, check "Merge to HEAD revision" to incorporate all the changes done in the branch, from its creation to the current most up-to-date revision
     
   • This will create a modified working set locally (the project linked to the branch will need to be committed)
     
   • At this stage, you need to update the project first (using Team -> Update) before the modified files can be committed
     
   • Finally, select Team -> Commit to publish the merged files into the branch
     
5. In the reverse direction, when you need to merge back changes from the branch into the trunk (where edits has been done in both the branch and the trunk), all you need to do is to select the project containing the trunk and select the branch as your "From" URL, you still need to select the revision number of the Branching commit (for all the changes you committed to the branch to be included and not just the newer or latest ones)  

I find a special shortcoming in the Subversion branching and merging system; when merging, it doesn't merge the changes in its revision number, meaning that if you did changes to the branched files in revisions 105,106,107 & 108 to the branch, and then merged and committed the changes to the trunk in revision 109, you will only see all of the changes suddenly occur to the file in revision 109 and later, not in an incremental way as it should be.

This is not a major shortcoming, as you can always return to the branch and check its changes in the revisions it was committed in, but it is still an unintuitive solution.

Experiments with Subversion

I've been experimenting with Subversion, and it turned out to be great tool, even for single developers, where its ability to indefinitely remember changes and track versions is indispensable to any software project that is more than a small hack.

Also the ability to work with it is very important to contribute to any major open source software (especially the ones I'm currently interested in as uDig, PostGIS and OpenLayers).

I'm using Subclipse and TortoiseSVN to handle the communication from and to my SVN repository, Subclipse is particularly easy and handles all of my needed functions with tight integration to the Eclipse platform; I've tried the Subversive and it didn't seem to recognize the SVN connector library (neither JavaHL nor SVNKit), I think the Subversive plug-in is more feature-rich, but until further attempt, Subclipse is very stable to me.

I've also read about Git, Mercurial and Bazaar, and I think the Distributed Version Controlling Systems are really interesting, but they seem to not fit so well with my development model, you can check about some notes about them here and here.