Status, IDE Generator (Miguel Garcia)

I've been refactoring, adding functionality, yet I had the uneasy feeling that something was missing ...

Big revamp of Chapter 1 ("Frameworks for text editors: JFace Text and Gymnast Runtime") of the project report. With that, a user of the IDE generator is also in a position to understand (and further customize) the generated IDE. Features are classified, code snippets and references to further literature given.

----------------------------------------------------------------------

The features per category are:

a) The Gymnast Runtime extension to the JFace Text framework

• background parsing and notification of changes to the CST of the document
• context outline (with nodes implementing navigation back to the text region, and property source)
• custom problem markers
• parse-tree view

b) Customizations requiring CST or AST

• hovers over text fragments
• hovers over annotations (annotations on the vertical ruler)
• hyperlinks
• mark occurrences
• select in outline
• show in
• context menu on the editor surface, for example Go to Declaration
• views, for example EMF Type Hierarchy
• content formatting
• content assist

c) Customizations directly working on the document text

• document partitioning
• show range indicator
• bracket matching (brace, parenthesis, etc.)
• AutoEdits (for example, SmartBrace: after typing { in the JDT editor, an indented newline and a closing } are added below it). Another example is AutoIndent.
• Double-click strategy (in JDT, double-clicking an opening brace selects all the text up to the matching closing brace)
• Automatic Indentation

d) Document-independent customizations

• templates, including associated Preferences page
• actions on the toolbar and menu bar, in particular retargetable actions (i.e., those actions whose UI activators are shared between different editors, such as e.g. Content Assist)
• new file wizard, so that the document does not start empty but in syntactically valid state (thus avoiding spurious parse errors the moment background parsing kicks in)
• Preferences
  

----------------------------------------------------------------------

It's incredible the amount of detail hiding in each feature ... an Eclipse-based text editor can really be a machine with lots of moving parts ...

http://www.sts.tu-harburg.de/~mi.garcia/SoC2007/draftreport.pdf

Status: Improving Eclipse Search

Last week, I decided to implement "Highlight All" feature mentioned in Bug 29692, since it's a common enhancement request. I believe I've produced a patch that solves it. However I'm planning to implement "soft matches", that is if the user requests it, highlighting case-insensitive matches with a different color, case-sensitive whole word matches with a stronger color etc. like Ctrl+H Search does.


About the "lightweight find" ( Bug 99294 ), you should read Comment #24 about my current thoughts. The only problem with having "Find" and "Replace" fields on the bar simultaneously is visibility of all labels,buttons,fields on the bar at the same time on a vanilla install. Iconizing "Find", "Replace", "Replace/Find", "Replace All" buttons would save some space (these button labels can be written as tooltips). About "Options" group presentation problem, I thought of a bar-switch behaviour or a second bar appearing on the Find/Replace bar.

Another solution would be adding a second bar to appear for Replace and Options (shared use). The scenario would be like this:

1. Press Ctrl+F. You'll see a bar under the editor.
Only the Find bar:

[x] Find: [_____] [Next] [Previous] [Options...] [Replace...]

2. Press Ctrl+F again. Another bar will appear under the Find bar. This should be Replace bar. Find bar will "reform" itself.

[x] Find: [_____] [Options...]

[x] Replace with: [_____] [Next] [Previous] [Replace] [Replace All]

3. Pressing button will switch the second bar (Replace bar) with an "Options" bar.

It's still very open to discussion so I'm planning to implement it after we settle on an idea.

I hope to tackle other usability issues next week together with lightweight Find/Replace design.

That's all. Thank you for your feedback.

Status: Multi monitors against the rest of the world

Just to recap in the case you forgot about my SoC project: I'm hard at work improving the user experience on multi-monitor systems in Eclipse.

After struggling with building SWT on Windows Vista again - which worked fine some days ago - I attached all my fullscreen related stuff to the appreciated bug report in the hope that some of the SWT guys are willing to review the patches and getting them into CVS in the next days/weeks.
When the fullscreen support is in place, I can care more about the Workbench implementation of handling fullscreen stuff. There is already a working solution available but I think we can improve the one ore other little feature to make our users happy :-) I'll attach the code to the bug report immediately after the SWT guys committed the fullscreen support. Then everyone can participate to discuss more feature wishes. If you already have some nice ideas, let me know - best place would be a comment on the bug report.

After talking to Eric Moffat - the guy behind the black magic called presentation - we came up with a possibly good solution regarding improved detached windows (sashes, min/max behavior, etc) by replacing the current Detached Window implementation with a lightweight Workbench Window. Let us see how far we can come with this approach. I'll report about my progress in this area after working some days on this to see if it's that right way to go.

Status: Semantic-aware component provisioning

Recap: My project is about semantic-aware software component provisioning. Student: Savino Sguera - Mentor: Philippe Ombredanne.

• previous status report
  
• all about my GSoC project @ Eclipse (new window, personal blog)
  

Most significant updates for this week:

• Model refactoring
  
• Ontology design improvement
  
• Jastor classes update
  
• Implemented marshalling subsystem (XStream)
  
• Added persistency to Jena model (Apache Derby embedded DB)
  
• Tested full stack data flow:
  Restlet's DomRepresentation <-> Document <-> XML <-> Javabean <-> Jastor class <-> Jena statements <-> RDBMS
  
• Discussed dependencies licensing issues (no problems ahead)
  
• Started client's architectural design (and assessed code reuse scenarios)
  
• Added javadoc
  
• Committed new code to eclipse-incub

Very next steps:

• Discuss some modeling issues with Philippe
  
• Implement REST layer
  
• Get a live demo of the repository up and running
  
• Start client design
  
• Add a "dependencies" page to project's wiki

That's all for now.

Status: Improving Eclipse Search

There is significant progress in the project since last week. I reflected my initial ideas and conceptual work in Bug 195455 . The support for lightweight Find/Replace enhancement was great. Thank you for all the great ideas and responses. Discussion about this feature is continuing in Bug 99294 now.

Currently, I'm implementing (3a) from Kevin McGuire's comment which is:

3) Have it take up space in the layout somewhere,
3a) current option is within the text editor itself ala Firefox

As of today, remaining work is showing Options group and Scope group in the Find/Replace dialog in a good style, adding shortcuts, making sure of good performance.

I've converted Direction group in the dialog having "Forward" and "Backward" radio buttons in it, to a compact button that switches the search direction. This saves a significant amount of space on the Find/Replace bar and will be far more functional than having 2 radio buttons for this task IMHO.



An issue that may arise when I'm implementing (3a) approach is supporting search in ConsoleView etc. (anything other than the editor) in a good way. I think of carrying the same functionality ( offering Find/Replace in a bar ) in Toolbar of the ConsoleView. I expect to face a few issues about searching outside the editor.

This is it for now.
You can keep track of my progress in lightweight Find/Replace from https://bugs.eclipse.org/bugs/show_bug.cgi?id=99294 .

Thank you for all the ideas,interest and support.

Semantic-aware component provisioning: status report

Recap: My project is about semantic-aware software component provisioning. In my previous status report I dealt with the SWPO ontology design and a first architectural sketch of the repository, other than taking some significant decisions REST URI and resources to be exposed by the repository REST interface.

• Project wiki
• Previous update

I am glad to report about some significant progress in my project this week.

- Slightly refined the SWPO ontology (will upload fresh snapshot on the wiki asap).

- Got a good grasp on (and generated typesafe OWL2Java code mappings through) the IBM Jastor framework <http://jastor.sourceforge.net/>, part of the IBM Semantic Layered Research Platform <http://ibm-slrp.sourceforge.net/>. Generated code readability is awful, and I had to overcome some defects in handling inheritance and RDFList's, but at least it relieved the burden of writing the data access layer and Jena interaction from scratch. I will get the JUnit bar stuck on green in the very next days.

- Refined the repository architecture: three-tier, handling requests and resources' representations in a "pipes and filters" fashion. Assessed the chance of providing both a parsing and a marshalling subsystem in the application layer (will update architectural views on the project wiki asap). What I wanted to achieve was (and still is) to decouple the application layer both from the RESTlet framework and the specific implementation of the Data Access Layer, as much as possible.

- Created a module and committed code to eclipse-incub (I am actually updating the module quite frequently).

After a quite late start, finally things are smooth and running fine.

Cheers,
Savino Sguera

Status: scripting plug-ins

Official name: Add the ability to write plugins using jruby or groovy

First of all a slight change in the priorities. The top priority now is to enable the support of the bundles that are implemented using scripting language, i.e. Groovy and/or JRuby.

Others nice to have features will be:
1) Enable custom processing for plugin.xml, to be able test the new plug-ins without starting the 2nd eclipse instance.
2) The console, for providing the interactive (re)loading of the plug-in.

I have described to issues in more details in my blog entry.

Status: Improving Eclipse Search

Official name: Eclipse search plugin: providing a better, faster, more relevant Eclipse search

July 5th

Since my last blog entry about the project, there've been changes in the main goals of the project after discussion with my mentor Francois Granade and Daniel Megert.

Here are the current goals of this project:

General Goal:

• Unifying "Search" facilities so that there won't be 3 different search (and replace) functionalities in Eclipse

Specific Goals:

• Unifying Ctrl+F (Find/Replace dialog) and Ctrl+J (Incremental Search) by mostly behaving like Ctrl+J. Providing better UI utilization by not showing modal dialogs if the user doesn't request wider options. Summary of the idea: Firefox-style "Find" with enhancements. = a lightweight Find/Replace. Our main goal here is providing all functionality available in Ctrl+F with this lightweight Find/Replace. Here's the related Bugzilla entry: https://bugs.eclipse.org/bugs/show_bug.cgi?id=195455
  

• Providing "bridges" between Ctrl+F and Ctrl+H. This means carrying query information and search parameters back and forth between them when it's possible. --- To explain it better, it doesn't mean "sharing" input/settings, it is enabling the user to transfer "Find/Replace" input/settings to "Search" easily and extend his/her current search scope & query.
  

• Investigate better presentation of the search results in Ctrl+H ( adding an alternative view like Problems view - results in a table - might be a good idea to show result lines and numbers, paths etc. )

Current Progress

I'm working on a lightweight Find/Replace ( first Specific Goal above ) right now. I've converted IncrementalFind's Label widget on the status bar to a Text widget and using IFocusService I've managed to give cut/copy/paste input to this Text widget when focused.



For this lightweight Find/Replace, I've tried to create a prototype figure and attached it the Bugzilla entry https://bugs.eclipse.org/bugs/show_bug.cgi?id=195455. What I have in mind was basically a "Find" field appearing on the statusbar first Ctrl+F and when the user presses Ctrl+F again, "advanced feature" set appears as a menu above the status bar showing necessary checkboxes,parameters etc. but this prototype figure and behaviour is open to change.



After adjusting the behaviour of the code a bit , I'm going to work on the floating menu that will show up when the user requests "advanced Find/Replace features" next week.

I've created a feature and an update site for the project but even though the feature exports fine, when the feature is installed on a new Eclipse installation, Eclipse doesn't start. I've also tried to create a Plugin Fragment project first (since I've made all my modifications to org.eclipse.ui.workbench.texteditor), and then create a Feature & Update Site for it. This time, everything worked fine except that my changes to org.eclipse.ui.workbench.texteditor didn't show up in the new Eclipse installation.

I've committed my work as a patch to "soc-search" module in "eclipse-incub". It's very primitive right now but you can checkout anytime and see what I'm doing. First take a look at readme.txt to see how to build the project.

Host: eclipse-incub.cvs.sourceforge.net
Repository path: /cvsroot/eclipse-incub
Module name: soc-search

Feel free to comment here or on Bugzilla. Thank you for your time and feedback.

Plug-in Dependency Visualization

A lot has happened in my Summer of Code project over the past few weeks. To recap, my project has two main objectives; 1) to bring plug-in (bundle) dependency visualization to the PDE and 2) to solidify Zest, an information visualization toolkit for Eclipse.

Zest came out of some work I was doing for Mylyn, but we are now in the process of moving it to GEF / Draw2D. However, until this happens, we are still in the Mylyn repository and went through the move with them. After a bit of work, we are up and running again.

Zest has also been refactored to offer two separate APIs for Directed Graph Rendering. One API resembles SWT and the other one, JFace. In fact, I have created a number of snippets to show how these APIs can be used to create a view with a directed graph. During the refactoring I also removed all dependencies on the Runtime (we are now runtime free). This means that you can use Zest in your standalone SWT applications. Of course I still use the PDE tooling, so the JARs can also be used as an OSGi Bundle.


Finally, I have added container support to Zest. I plan on using this to group bundles in the dependency view. This should help with the scalability problems you get when you try and render a large graph. Nodes can now be added to containers and the containers can be expanded / collapsed. I am pretty sure I completed this without breaking any existing API, but if you use Zest and I broke something, please let me know. This feature was fun to implement, however, there are still some open issues. In particular, how to deal with connections that go from nodes in one container to nodes in another, and nested containers.