Ease of use (including ease of learning) and following Eclipse Workbench standard behavior are two of many things we try to include in all our designs. However, sometimes these two things are at odds and we have to choose one or write extra code to compromise on a solution. Over the past few weeks we’ve run into 3 good examples of this working on RDi 7.5 which I’m going to include here for comments on:
1. In Eclipse 3.4 (or Eclipse 3.3) the Plug-in Development Environment (PDE) added a new keyboard shortcut: Ctrl + Shift + A to open a plug-in artifact. RSE users will recognize this keyboard shortcut as the “Open Member” dialog. So now when you press Ctrl + Shift + A, Eclipse detects the conflict and pops up a little conflict dialog:
We (the RSE development team) had 3 choices: (1) Change our keyboard shortcut, (2) attempt to write some code to disable the PDE action, or (3) leave the conflict. Option (1) was ruled out because changing our action will make existing users frustrated because they are used to the old key sequence, and it doesn’t guarantee there won’t be future conflicts. Option 2 is out because it’s generally considered a bad practice to do something like this in the Workbench.
I believe option 3 is the best option because Eclipse already provides a preference page (General > Keys) where users can customize keyboard shortcuts. So really option 3 leaves it to the user to resolve by either changing the keyboard shortcut assigned to one of the actions or removing the key binding for the one they don’t want.
As a design rule, I’d like us to leverage the existing Eclipse workbench as much as possible for things like this instead of writing more code to resolve the issues (which can make things more complicated in the long run IMHO). Of course the shortfall of option 3 is that you have to know that you can customize the keyboard shortcuts via the preferences. The pop-up dialog does hint at this with the “Press Ctrl + Shift + L to open the preference page”.
2. The second example was around the current line color for the debug editor. The default editor used by the debugger is the Remote Systems LPEX Editor. The default current line color for the editor is pale blue that is hard to see. Again this can be changed by a preference (LPEX > Appearance) if you know where to look. In past releases we did some extra coding to override the preference and make the current line darker blue while debugging.. This release some things changed underneath us in the software stack and that no longer work. We ultimately decided to not re-implement this override since the preference already exists.
3. In the RSE you can right click on a local save file (local being on your PC), right click and select the Restore on IBM i… action to restore the save file on one of your IBM i connections (yes connections are now IBM i in 7.5 instead of i5/OS in 7.1 and iSeries before that). Previously this action ran on the user interface thread and blocked any refreshes of the Workbench (so the Workbench appeared hung during the upload and restore). We wanted to change this to run asynchronously and even give the user the option to run it in the background and continue doing other things. The design question was: what to do when the action completes with errors? The standard Eclipse progress task just puts an icon in the bottom right corner of the workbench with and explanation mark on it:
If you click the icon then a dialog box appears showing the results. Of course, you have to know to click the icon to see the results. The alternative would be to always show a dialog box when the action completes, but that could become annoying if you are in the middle of doing something like enter some source code. The jury’s still out on this one.
Ultimately we want the RSE to be easy to use and follow standard look and feel guidelines (which makes it easier to use in the long run). Like every other development team we also have fixed resources and implementing a workaround for something means something else doesn’t get done.
I’d love any comments that new or existing users have on this topic to help us in our future decisions!
Doing some more testing this morning and I stumbled across this in the online help (WDSC 7.0):
So the keyboard shortcuts are documented in WDSC! This will be handy to know.
I’m currently running some old testcases for the editor and I came across one that included these steps (while editing CMD source):
- Position your cursor at “(” and press Ctrl + Shift + M
- Cursor should reposition to the matching “)”
I knew we had a match function, but I had no idea it would match brackets too! So I had to try it with RPG and sure enough it works there too! Bottom line: there are a lot of features in the RSE, epecially the Remote Systems LPEX Editor. I’m really looking forward to reading the editing chapter that Nazmin is currently work on to see what else I’ve been missing out on : )
As for my progress on the book, I just finished up my big chapter which basically covers the Remote Systems view (connections, filters, working with libraries, objects and members, iSeries table view (which perhaps should be a separate chapter, but is closely related to the other stuff), and filter pools. I resisted putting a section on profiles, but the more I think about it the more I’m inclined to include one. Probably in a different “miscellaneous stuff” chapter. Now I’m onto the iSeries projects chapter.
I used to say the only reasons for using iSeries projects was:
- Disconnected development
- More structured development (i.e. organizing applications into projects which ideally are finer grained than the large libraries typically used today)
- Change management (being able to store your RPG, COBOL, CL and DDS in the same repository as your Java and Web pages)
However, I have recently been surprised by the uptake of iSeries projects for different reasons. One person on the midrange.com WDSC mailing list was being forced to keep their html files used with CGIDEV2 in a source physical file member on the System i. This makes it very difficult to use a graphical editor like the Page Designer in WDSC because the graphical HTML editors can’t handle the sequence number and timestamp fields. In WDSC 7.0 we added a feature that can have iSeries projects automatically strip off the sequence numbers and timestamp field from each line when the member is downloaded. Using this feature the user was able to use iSeries projects and Page Designer to edit their HTML source members.
Others use iSeries projects to edit their RPG, COBOL, CL or DDS source members solely for the ability to have the workspace track the changes. As you save changes to a local workspace file, the workspace support tracks the changes as a local history. You can then right click on the member at any time and select Compare With > Local History to see each saved change and compare your current edition to any of the saved changes. This capability is not available when editing from the RSE.
This can even work if nobody else on your team is using iSeries projects. Before you make changes to your member, right click on it in the RSE and select “Make Available Offline” (nevermind the fact that you are not working offline). Then from iSeries projects, make your changes to the member. When you are done, right click on the member in iSeries projects and select Remote Actions > Push Selected.
There are a couple things to consider here. When you edit members with the RSE they are locked on the System i just like when you edit them with SEU. So nobody can makes changes to the member while you are editing it. With iSeries projects the member is not locked. So when you go to push your changes you might get a warning that the member has been modified while you were changing it. How likely this will happen and steps you could take to reduce / eliminate this will vary depending on how your shop has it’s development environment setup.
Of course, implementing a change management system would solve the locking problem and give you the ability to track changes :)
A list of Windows XP keyboard shortcuts from Microsoft: http://support.microsoft.com/kb/301583 most of which will work in WDSC.
I picked up a new one today: Shift + F10 to bring up the pop-up menu. Lately I’ve been using the keyboard almost exclusively to navigate tree views (Remote Systems views, Project Explorer) but always had to go back to the mouse when I wanted to run an action. Now I can do that with the keyboard too :)
Your RSE connections, filters, user defined actions, and custom compile commands that is.
In order to use the RSE most effectively you will have created (or still need to create) lots of connections, filters, filter pools, user defined actions, custom compile commands (I’ll call these “artifacts”). Now, how much of a super hero would you be if you then shared all that hard work with your team members so they didn’t have to redo all the setup you’ve already done? Even if you don’t want to be a super hero, you should still at least backup all your hard work.
This capability was designed into the RSE from the start, and is the reason you see a prompt for “Profile” at the top of every dialog that creates these RSE artifacts. If you switch to the team view in the RSE you will see these profiles:
Most likely you will only have two profiles: a Team profile and your own profile that you named when you created your first connection. The profiles are stored in a workspace project called “RemoteSystemsConnections”. Under each profile are all the RSE artifacts owned by that profile. There is no special connotation with the name of the profile (Team profile is just the same as ABC profile). Profiles are just groupings of RSE artifacts.
If you copy this entire project (using the workbench export / import actions) to a new workspace then all associated RSE connections, filters, etc… will show up in the new workspace. Alternatively you can copy over only a single profile. Use either the General > File System or General > Archive import / export options.
From the RSE team view there are actions on profiles to make them Active / Inactive. All RSE artifacts owned by active profiles are shown in the RSE. RSE artifacts owned by inactive profiles are NOT shown in the RSE. So another use of profiles is to hide RSE artifacts related to projects you only work on once in awhile.
Say for example you only have to update the accounts receivable application once every couple of months. Then create a profile called “AccountsReceivable” and create all RSE artifacts (connections, filters, UDA) for the accounts receivable project under that profile. You can then easily hide them from the RSE when not needed by making the profile Inactive.
Again, this capability was originally designed to share RSE artifacts in a team environment and is documented in the online help under: WebSphere Development Studio Client for iSeries > Developing iSeries server applications using the Remote System Explorer > Sharing team-managed development resources. But it can also be used for simple backup, or copying between your own workspaces (or recovering RSE artifacts from a corrupted workspace). The help mentions synchronizing the project with an SCM repository (CVS, Subversion, IBM Rational ClearCase) which is ideal for sharing ongoing changes, but you can also just use the export / import way.
I was just writing some COBOL source code (which is a challenge since I don’t really know COBOL) to test some of the new features we are working on when I cam across a cool editor feature for COBOL that I didn’t know we even had for COBOL. And it doesn’t exist yet for RPG!
Normally when we add new features to the RSE we put them in for RPG first and then COBOL either at the same time or later on. Simply because RPG is more widely used on System i than COBOL.
Back to my story. Like any good programmer I was trying to add comments to my source. Not knowing how COBOL expects comments to appear, I first tried // comment. Nope, synatx error. Next I tried /* */ which worked, but at the same time I accidently hit some key combination that put a * in column 7. Updated: apparently /* */ doesn’t work.
Whoa, backup. We have an auto comment / uncomment action for COBOL? Apparently so. Just like the Java editor, if you press Ctrl + / it automatically comments out the current line (or selection of lines). And Ctrl + \ automatically uncomments the line.
I’m going to assume that kudos goes to Adrian for that one. Now, if we only had that for RPG like everyone asks for :)
For some reason this week I keep finding myself with a lot of open editors and wanting to close all of them except for just one or two. Normally I’m working on a problem and someone stops by and we get off track investigating something else. When they leave I want to close all the other editors to get back to my original task.
I’ve discovered a pretty cool way to do this:
- Press Ctrl + Shift + E which opens the Switch to Editor dialog.
- Select the editors you want to keep open.
- Click the “Invert Selection” button.
- Then click on”Close Selected Editors”.
Viola, only the editors you want are still open. I’ve been using this with the Java, XML and properties file editors, but because of the beauty of Eclipse it works for any editors, including the Remote Systems LPEX editor for RPG and COBOL.
I was playing around with the integrated iSeries debugger in WDSC the other night and stumbled across two features I’d never noticed before and thought I’d share them here. In the Breakpoints view you can specify different ways to group breakpoints by selecting Group By > HowYouWantToGroup from the views pull down menu (that’s the upside down triangle). For example, if you are debugging a multi-tiered application and have some RPG, Java and JSP breakpoints, you could select Group By > Breakpoint Types to see them categorized by type. Here is an example:
The other feature is you can add multiple renderings to the memory view for a single field. When monitoring memory (right click on field and select Monitor Memory > Rendering) you see a list of all fields on the left side and when you select a field you see it’s memory on the right side with the rendering you selected when you added the field to the view. However you can add additional renderings by clicking on the plus sign in the top right corner of the view (there are two plus signs in the view, one adds additional fields and the other adds additional renderings for the selected field).
Background: the memory view shows the contents of memory for that field. If you select Hex then you see the raw bits. A rendering takes those raw bits and displays them as a data type; as EBCDIC for example. You can add your own renderings for Java and I believe there is a way to do this for RPG and COBOL. I’ll post that once I figure it out.
Even as a technical team lead on WDSC, I continually learning new things the tools can do. Paul Tuohy said in his keynote at this years TUG TEC conference, playing is one of the best ways to learn. I couldn’t agree more!
The current issue (August 2007) of the IBM Systems Magazine, i5 Business Systems edition, has a “Favorite Keyboard Shortcuts for WDSC” pin-up created by System i Developer. Unfortunately I can’t find a link to it online, but the magazine subscription is free.
I’ve memorized all the standard Windows shortcuts and Eclipse navigation shortcuts but I can never seem to remember the LPEX shortcuts so I now have it pinned up in my PWA (personal work area, aka cubicle). I’m hoping it falls within the IBM guidelines of appropriate and non-confidential materials :)
The pin-up also lists the outline view as the the System i Developer’s favorite WDSC feature. Which got me thinking; what is my favorite WDSC feature? Outline view, application diagram (I’m biased on this one), and extensibility are definitely runner-ups. But my favorite feature is without a doubt service entry points!
So, what’s your favorite?
Updated 09/20: A PDF of the pin-up is available on the System i Developers website here.