A better kind of GUI

VA Smalltalk is a "100% VisualAge compatible" IDE that includes the original VisualAge technology and the popular VA Assist and WidgetKit add-ons.

Moderators: Eric Clayberg, wembley, tc, Diane Engles, solveig

A better kind of GUI

Postby tc » Wed Jan 12, 2011 12:37 pm

Hello,

From http://joachimtuchel.wordpress.com/
a much better kind of GUI, which make source code browsing within the system even more productive

I'm researching items for possible inclusion in the road map of future items. More details makes it easier to get an item in the road map.

As to this issue, what would a 'better' source code browser look like or what key features would it have?

Thanks.

--tc
tc
Moderator
 
Posts: 304
Joined: Tue Oct 17, 2006 7:40 am
Location: Raleigh, NC

Re: A better kind of GUI

Postby louis_andriese » Wed Jan 12, 2011 1:24 pm

Louis Andriese
Manager ICT
Nationaal Spaarfonds (part of Delta Lloyd Group)
Waalwijk, the Netherlands
louis_andriese
 
Posts: 20
Joined: Thu Dec 13, 2007 5:19 am
Location: Waalwijk, The Netherlands

Re: A better kind of GUI

Postby koschate » Wed Jan 12, 2011 3:01 pm

I'd really like to see a modernized version of TrailBlazer, one that includes all the VA Assist Pro goodness, using tabs rather than the piano key approach of yore, and therefore allowing easy jumps between the panes.
koschate
[|]
 
Posts: 102
Joined: Thu Feb 01, 2007 7:24 am

Re: A better kind of GUI

Postby jtuchel » Wed Jan 12, 2011 3:48 pm

Louis,

thanks for the links.

Since my posts are a few weeks old, I'd like to add a few thoughts here:

* There is two dimensions to the problem of VAST code tools.
* Short term, cleaning up the existing ones would surely help (see the first two posts for some suggestions)
* Mid to long term, this will by far not be enough. It is time to rethink some of the tools and the way they work. There is a lot that can be learned from Eclipse's views and perspectives model, but that is not sufficient for VA Smalltalk. Browsing Smalltalk code requires much more than just a view of a class hierarchy. A Method has more context than just a class, there's also the complete set of Envy's code management relationships. I am talking of Applications, Maps etc. and their relationships. So depending on a Task, navigating through the image can have very different aspects. There are several perspectives on the context an artefact lives in.

What I try to say is that we need a model of what browsing code really means in the context of several tasks. The latter posts linked to cover some ideas of mine on the topic. And I am sure once we dive deeper into an analysis of how people search, read and modify code, we'll find much better interaction models than today's Smalltalk Browsers.

Let me repeat an example from my posts:
If you look at the Class Editor you can switch between three perspectives of a class: the visual composition editor, the script editor (=class browser) and the Public Interface Editor. These three are just three perspectives on the same thing. In a Tabbed Browser, they should just be three additional tabs in the bottom pane where you also have the perspectives on other aspects of a class, like the class definition tab and the source, comment and notes tabs. So we are coming to an end where all kinds of code editing end up as a tab in a tabbed browser. Or in separate windows, or in Eclipse-like perspectives... you get the idea. In the end there could be a setting to keep all perspectives in one window or open all or some of them in their own windows etc. (Think Xcode). And we are coming to a point where all browsers are really the same thing, just the number and combination of code perspectives (and with them the contents of the menus) change. Sounds familiar? Yes, take a look at WindowBuilder Pro for Eclipse, which once was an Instantiations product. It shows exactly what I mean.


There is another point to make here, and this would be an investment into the short-term as well as the long-term goals:

Invest into the editors.
It should be possible to show line numbers, add icons right into the text (Breakpoints, Red warning signs etc.), show Lint results and hints. Add hints like highlighting corresponding brackets when the cursor is on a bracket. All the stuff that's been around in other IDEs for ten years now. Let me fold/unfold parts of a method.
The argument that Smalltalk methods are short anyways and such features aren't needed are simply wrong. I see lots of multi-page methods in my customer projects, and even the VAST base code includes loooong methods. Add nonsaving code formatting. There are artists out there who manage to format an 8-liner in a way that you understand nothing without reformatting it. Which creates a new edition.

And please make the changes Browser like it is in Pharo or in Eclipse. It would help a lot in understanding code changes.
jtuchel
[|]
 
Posts: 245
Joined: Fri Oct 05, 2007 1:05 am
Location: Ludwigsburg, Germany

Re: A better kind of GUI

Postby tc » Wed Jan 12, 2011 7:57 pm

Hello,

I'll read your links and post questions. There are many ways to skin a cat but I don't think I can change the world (ie a massive browser rewrite) on the first pass.

However, if we can get an agreement here on some changes then I think it will be easier to get the changes approved internally.

--tc
tc
Moderator
 
Posts: 304
Joined: Tue Oct 17, 2006 7:40 am
Location: Raleigh, NC

Re: A better kind of GUI

Postby jtuchel » Thu Jan 13, 2011 12:26 am

Taylor,

I think we'll have a much better tool after some serious cleanup of menus and when the different browsers are unified. That would be a very good first step.

As I mentioned: Some things can be done gradually, and there are quite a few possibilities for making real progress in supporting a developer's workflow by rethinking stuff. Work on this would be innovation, while the short-term stuff is just renovation.

The only thing that should be completely rewritten quite soon is the changes browser.

Joachim
jtuchel
[|]
 
Posts: 245
Joined: Fri Oct 05, 2007 1:05 am
Location: Ludwigsburg, Germany

Re: A better kind of GUI

Postby TriSebastian » Thu Jan 13, 2011 6:37 am

Hi all,

I'd have one little whish for a next Release.

There are several little bugs in VASt regarding the backgroundcolors of components. Have you ever tried to give a TabbedView or Notebook a different color than the default one?
It looks ugly. there still stay little parts with the default color and there's no way to change this.

I would also appreciate a little more support on custom toolbars and Bitmaps/Icons,....

Have alook at the windows copy details window including an animation when you are copying data from one folder to another. Such little things would really be beneficial. "XXX Sells"

Sebastian
TriSebastian
 
Posts: 76
Joined: Sun Jul 20, 2008 9:40 pm
Location: Nanaimo, BC, Canada

Re: A better kind of GUI

Postby jtuchel » Wed Jan 19, 2011 7:01 am

Hi again,

talking of the changes browser: Apart from Eclipse an Pharo there is another great source of inspiration for a good diff/merge tool: Apple's Xcode. It not only shows you the differences between two versions (inserts, deletions, changes), but also a preview of the merge result. And it's nicely integrated into the workflow.
You can see a screenshot of it here: http://www.flickr.com/photos/linmagazine/2236589413/
This makes merging in Objective-C really a nice job as compared to what we have in VAST...
jtuchel
[|]
 
Posts: 245
Joined: Fri Oct 05, 2007 1:05 am
Location: Ludwigsburg, Germany

Re: A better kind of GUI

Postby benvandijk » Thu Jan 20, 2011 2:46 am

Ï agree with Joachim,

Please cleanup the browsers first and then modernize them.
I know there are more ways to browse classes in VA and every class browser has
different menu options.

I have a simple wish for a popup menu that shows the existing method names
in the class i am editing and copy the name from the list to the code i am typing.
benvandijk
 
Posts: 45
Joined: Sun Feb 25, 2007 7:14 am
Location: Arnhem, Netherlands

Re: A better kind of GUI

Postby daswartz » Mon Jan 24, 2011 5:35 pm

The only thing that should be completely rewritten quite soon is the changes browser.


+1 for rewriting the changes browser with code merge support as the first step.

Doug
daswartz
 
Posts: 48
Joined: Sat Oct 21, 2006 8:12 am
Location: Omaha, USA

Re: A better kind of GUI

Postby TriSebastian » Tue Jan 25, 2011 6:45 am

Moin!

Yes, that would definitly be fine!

In addition to that I would love to see a fully XML capapable Editorlike Widget.
Working with Web Services, wsdl, dataschema and so on is sometimes quite hard using those string representations... additional inverted commas make live hard while editing, inspecting,.... xml sources.
Even copy&paste those sources for further editing into other external tools is no big help there.

Sebastian
TriSebastian
 
Posts: 76
Joined: Sun Jul 20, 2008 9:40 pm
Location: Nanaimo, BC, Canada

Re: A better kind of GUI

Postby tc » Mon Jan 31, 2011 7:10 am

Hello,

. . . we'll have a much better tool after some serious cleanup of menus . . .

I looked at the menus for the CHB and they are put together by methods up and down the class hierarchy. Also, when a feature is loaded, that feature may modify menus all over the IDE. What to do about it will be discussed internally as a possible road map item.

--tc
tc
Moderator
 
Posts: 304
Joined: Tue Oct 17, 2006 7:40 am
Location: Raleigh, NC

Re: A better kind of GUI

Postby tc » Thu Feb 03, 2011 3:47 am

Hello,

+1 for rewriting the changes browser with code merge support as the first step

The question I'll be asked is why not use the MED 3-way differences browser (which has code merge support)?

--tc
tc
Moderator
 
Posts: 304
Joined: Tue Oct 17, 2006 7:40 am
Location: Raleigh, NC

Re: A better kind of GUI

Postby jtuchel » Fri Feb 04, 2011 3:51 am

Taylor,

- because it does not give much of a visual hint as to what the changes between two editions are
- because it's not the merge tool that I have out of the box
- because it has the look&feel of VisualAge 3.0.
- because the world has turned a bit since 1996 and people want both helpful and good-looking tools
- because the merge tools in Squeak, Pharo, Xcode, VisualStudio, VisualWorks, Eclipse and possibly many more IDEs are much better functionality- and appeal-wise
- because the longer we (pretend to) remain happy with our existing, somewhat limited tools, the more left behind we'll be over time
- because I have to think very hard when I use the envy diff browsers (including the MED TWDB), while other merge tools with their visual marks that clearly show insertions, deletions and changes as well as unchanged regions of my methods are much more intuitive and I lose time merging code because the tool forces me to be 100% awake and think about every step twice or better three times
- because this eats up some of the much-cited Smalltalk productivity advantage to a level where it can be painful in maintenance of legacy code
- because following changes and comparing editions of methods is a significant amount of code maintenance (I'd rather concentrate on why some changes were made and what's probably wrong with them than on what exactly the diff browser wants to tell me by selecting 15 lines in the left pane)
- because the last two arguments combined mean real $$$ for existing, long-term customers who have a code base that has grown over 10 or 15 years

I know and agree that as long as the primary auditorium for changes is just the existing customer base, functionality is much more important than look or feel. We are used to the way VAST looks and feels and don't care much, just as a Squeaker possibly doesn't care much that Squeak looks strange to outsiders, because we know that there's a lot of power in Smalltalk.
jtuchel
[|]
 
Posts: 245
Joined: Fri Oct 05, 2007 1:05 am
Location: Ludwigsburg, Germany

Re: A better kind of GUI

Postby jtuchel » Fri Feb 04, 2011 4:43 am

tc wrote:Hello,

I looked at the menus for the CHB and they are put together by methods up and down the class hierarchy. Also, when a feature is loaded, that feature may modify menus all over the IDE. What to do about it will be discussed internally as a possible road map item.

--tc


I guess the best thing to do is to keep the existing api and build up a new one that cann still be used in #loaded/#removing. That way existing third patry tools won't break, and you have time to use the new api for your deliverables over time.

One idea:

We could classify menus by what they operate on, like versioning/config management, source code editing, naviagting in the image or library etc, and define extension points, so that adding a menu item is requires at least two, maybe three parameters, something along the lines of:

registerMenuItemNamed:selector:receiver:forMenusActingOn: (class/instance/hierarchy...) functionalAreas: (#editing #envy #hierarchy #applicationStructure)

Just a very raw idea...
jtuchel
[|]
 
Posts: 245
Joined: Fri Oct 05, 2007 1:05 am
Location: Ludwigsburg, Germany

Next

Return to VA Smalltalk 7.0, 7.5 & 8.0

Who is online

Users browsing this forum: Google [Bot] and 1 guest

cron