New Topic To Beat Into the Ground
Locked
Re: New Topic To Beat Into the Ground
 
|
Adrian Kuhn wrote: > Forgot this one > > I never use spawn. > (or any other command that opens a second browser window). > > I use spawn very often to put some code aside in a separate window in order to use it as a reference while coding something new (e.g. a list of available selector names, old source currently being rewritten, etc). Spawning is a great reference "notepad" utility. Andre |
Re: New Topic To Beat Into the Ground
|
|
In reply to this post by Dennis smith-4
Dennis Smith wrote: I don't really see any reason to duplicate things in right-click in the menu. This is "standard" in almost all operating systems. Right-click is considered a shortcut and narrower selection of items for convenience only. At least for the views taking over the role of the "main" editor thing. Andre |
Re: New Topic To Beat Into the Ground
|
|
In reply to this post by Charles Adams
I guess this is now going off topic somewhat as the original question
was what to remove from RB as opposed to new functionality. Nonetheless for the record I would like to have the ability to drill down through implementations/senders of methods called by the currently selected method. Similar to current method list context menu items "implementors" "senders" and their hierarchy counterparts. The drill down should work much like trippy, by re-using the current method view or source tab so as not to open separate browser windows. Also similar to trippy, a history tree would allow backward/forward navigation e.g. back to originating method with a single click. Ideally, one should be able to double-click on a called selector within the existing method source and drill down to its implementation, refocusing the browser accordingly. If something like this already exists out there, please let me know. cheers Denis On 3/22/07, Charles Adams <[hidden email]> wrote: > > > On 3/21/2007, "Adrian Kuhn" <[hidden email]> wrote: > > >Forgot this one > > > >I never use spawn. > >(or any other command that opens a second browser window). > > > >Reading this thread I realize that there might be to schools of RB > >users, the one-window school, using tab, and the multi-window school. > >I personally belong to the one-window school, and would love to have > >a way of telling RB that ALL new browsers window should be opened as > >tab in the existing window. > > > > Now there's a great idea. > > |
Re: New Topic To Beat Into the Ground
|
|
In reply to this post by Sattler, Thomas (IT)
Please don't throw out HardCopy. I use it all the time. It's a great
way, I think, to get a snippet (or anything else you might paste into a workspace) printed without leaving Smalltalk. Sorry, Thom ;-). Diana Sattler, Thomas (IT) wrote: > Personally, I like spawn. > > I'd agree to get rid of Hardcopy, though. > > And, while we're on the subject, let's either upgrade, or eliminate > entirely, one of the least-used pieces of VW: the Ad Hoc SQL tool. I > know it's not technically a part of the RB, but it is put into the menu > stucture when you load a database parcel. In its current form, it is > essentially worthless. > > When you execute a query, the result grid is a Table widget, which means > you cannot resize the columns. If you use Sybase, which we do at Morgan > Stanley, and your result is a Timestamp or a Double, the cell isn't wide > enough to see the entire value, so what's the point? Some people have > rewritten this using an Aragon Table Widget, or just abandoned it > entirely and downloaded one of the many free SQL tools that are floating > around the internet. So my suggestion to Cincom is to either put some > effort into this thing and bring it up to some degree of usefulness, or > just dump it entirely. > > > > >> -----Original Message----- >> From: Ladislav Lenart [mailto:[hidden email]] >> Sent: Wednesday, March 21, 2007 3:05 PM >> To: [hidden email] >> Cc: VW NC >> Subject: Re: New Topic To Beat Into the Ground >> >> Travis Griggs wrote: >> >>> I'm going for an "original" topic to beat to death here. :) >>> >>> All software accrues features. Over time, it turns out that some of >>> the features become obsolete. Or of little enough value, >>> >> that carrying >> >>> them forward is not worth the cost, because they get in the way of >>> other things. The "Lean" thing. There are some obvious >>> >> advantages to >> >>> doing so; by vigilantly keeping your interface simple, the >>> approachability is that much better. So... if you could >>> >> take as many >> >>> as 4 (or less) things out of the Refactoring Browser, what >>> >> would they >> >>> be? What are the items you look at and find yourself >>> >> saying: "Why is >> >>> that still in there? I never use that? And I would never >>> >> show a newbie >> >>> that." Just the Browser please. If you want to nominate >>> >> another tool >> >>> to remove 4 things from, throw that at the bottom and we >>> >> can start another thread. >> >> Hello, >> >> I also don't use cut, copy and paste icons in the RB's toolbar. >> >> As I am thinking about it now, I don't use toolbar icons at >> all nor do I use main menu of the RB. I only use shortcuts >> and context menus. >> >> Next I don't use 'Spawn' and 'Hardcopy' in Protocol. Just a >> second ago when I was looking at th RB for something I don't >> use, I clicked 'Hardcopy' and was pretty shocked that the >> printer started to print... :-) >> >> Oh, and I don't use View/Zoom. I recall like it was yesterday >> when I pressed Alt+Z by accident (I didn't even know what I >> pressed) and was completely lost because half of my browser >> was gone... :-) >> >> Hope this helps, >> >> Ladislav Lenart >> >> >> >> > -------------------------------------------------------- > > NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. > > > > |
|
|
If you are going to keep hardcopy, then at least make it work right. It
should ask you what printer to send it to and it should nicely format the code. The indentation is way too big and there's no highlighting of method names, no indication of what class this is for (when you hardcopy methods). David Buck MerryShapiro wrote: > Please don't throw out HardCopy. I use it all the time. It's a > great way, I think, to get a snippet (or anything else you might > paste into a workspace) printed without leaving Smalltalk. > > Sorry, Thom ;-). > > Diana |
Re: New Topic To Beat Into the Ground
|
|
In reply to this post by Travis Griggs-3
On Thu, 22 Mar 2007, you wrote:
> Travis Griggs wrote: > > So... if you could take as many as 4 (or less) things out > > of the Refactoring Browser, what would they be? What are the items you > > look at and find yourself saying: "Why is that still in there? I never > > use that? And I would never show a newbie that." > > This is, perhaps surprisingly, a very difficult question. I *use* the > browser constantly, but I don't often look at it to figure out what it > could do that I don't use. > > So for me, the only answer is (seriously): > > Remove four features that I don't know are there. Oh, but don't > remove the features I don't know are there but would use all the time if > I only knew they were there. Only remove the ones that I wouldn't use > even if I knew about them. Too true. Now, without even a whiff of jest. I am completely new to this Smalltalk way of thinking and my fist impression was and to some extent still is: "Goodness me how on earth am I going to get my head around all this lot"? In other words I was completely overwhelmed. If you could offer a heavily stripped down starter's UI, which could be very simply extended, that would make climbing the learning cliff-face considerably easier, because at the moment there are too many features 'in your face'. Naturally there would have to be some run-conditions file of what extra UI features the more advanced user has enabled so that new upgrades come to life with all those features re-enabled. -- CS |
Re: New Topic To Beat Into the Ground
|
|
On Mar 21, 2007, at 21:11, Christopher Sawtell wrote:
So without knowing what exactly you'd be removing... tell me what you'd have left? You've played a little so far, what have you seen as the bare minimum? The simplest IDE that could possibly work so to speak? -- Travis Griggs Objologist "It’s actually much easier to get around on ice than it is on dry land—if you use skates." - Paul Graham |
|
|
In reply to this post by Tim Hutchison
I do second Explain, too. It is very useful für newbies, students for
example1 Johannes Am 21.03.2007 um 22:19 schrieb Tim Hutchison: > I second Explain. Use it all the time. > Chris Winemiller wrote: >> Randy Coulman wrote: >>> I don't use Explain, Hardcopy, Zoom, or parcel view. >> I use Explain constantly. It's a handy way to open a browser on a >> method or class. >> >> Chris >> >> >> > > |
Re: New Topic To Beat Into the Ground
|
|
In reply to this post by Travis Griggs-3
My turn!
Death to the parcel view. Death to undo/redo.. since it never works out the way I expect it.. I guess that's not really a death to, more like a jihad on. Death to redundant menu options like the refactoring ones. A particularly nasty death to Hardcopy, for all those times I accidently clicked on it. Death to the miriad of find options, also opting for a spotlight ripoff. Another particularly nasty death to protocol spawn, for all the times i clicked on it and waited for it to actually do something. It never has. Death to the Local Image, for taunting us with the idea that we could browse something other than the local image. Death to the three different ways we can look at change sets in the pundle browse submenu. Death to the cryptic * and + and whatever other crazy symbols that are meant to mean something that appear next to pundles. Death to menu items that have to explain themselves with brackets, such as "Remove (Unload)". Death to Set as current, whatever that means. Death to class probes and various other probing menu options when alls I really want is the ones in the method text area where I write code. Death to 'Find method' on the protocols popup menu. Death to submenus like 'Shared Variable' when you've clicked on a method. Death to the shortcut of the instance variables popup menu for Remove and References both being R. Death to the weird class hierarchy widget that isn't a tree that is indented like a tree. The email said list 4 things. I only listed three: Death, a particularly nasty death and Jihad. And don't be thinking I don't have a trout shield. Michael > I'm going for an "original" topic to beat to death here. :) > All software accrues features. Over time, it turns out that some of > the features become obsolete. Or of little enough value, that > carrying them forward is not worth the cost, because they get in the > way of other things. The "Lean" thing. There are some obvious > advantages to doing so; by vigilantly keeping your interface simple, > the approachability is that much better. So... if you could take as > many as 4 (or less) things out of the Refactoring Browser, what > would they be? What are the items you look at and find yourself > saying: "Why is that still in there? I never use that? And I would > never show a newbie that." Just the Browser please. If you want to > nominate another tool to remove 4 things from, throw that at the > bottom and we can start another thread. > > -- > Travis Griggs > Objologist > "It’s actually much easier to get around on ice than it is on dry > land—if you use skates." - Paul Graham > |
Re: New Topic To Beat Into the Ground
|
|
In reply to this post by Boris Popov, DeepCove Labs (SNN)
But you can't do that when you want to highlight text within a method
(even one you have not yet accepted) and see the implementors of what you highlighted. Chris Boris Popov wrote: > But you could also right-click on a class in the code and say "Browse > Class in New Window", same for implementers, senders etc; there's quite > a few context sensitive items in the right-click menu, no need to go to > the launcher, > > -Boris > > |
Re: New Topic To Beat Into the Ground
|
|
Chris Winemiller wrote:
> But you can't do that when you want to highlight text within a method > (even one you have not yet accepted) and see the implementors of what > you highlighted. Well, I know this is off topic, but it might be interested for Chris and others... We enhanced paragraph editor with ability to browse Namespaces, Classes, methods (or any symbols for that matter) or references to them. The usage is simple. Let's say you have the following written in a text editor pane: someAction: anObject anObject do: #something with: self. When you place cursor inside some|Action and hit F6, new browser opens with all references to #someAction:. When you hit F7, new browser opens with all implementors of #someAction:. The same pays for symbol #something. When you place cursor inside anObj|ect and hit F7, new browser opens on Object class. When you hit F6 new browser opens with all references to Object class. It is even possible to browse multiword messages, just place cursor inside the first word of the message and hit Shift + FX. If more than one multiword messages exist in the system that start with that word, popup menu opens where you can select the appropriate one. The same mechanism works for class names as well, even with namespaces: Smalltalk.Cor|e.Object opens browser on Object class. And if you like to browse just Core namespace in the example above, simply select the Core word and hit FX. This feature is especially useful in comments, because it effectively makes them hyperlinked - you can immediately browse Classes and messages from them without need to retype their names somewhere else. Ladislav Lenart |
RE: New Topic To Beat Into the Ground
|
|
In reply to this post by Travis Griggs-3
Great topic. I wonder if it would also be constructive at
some point, to get a consensus on “best practices” in development and browsing. What people use most, and what they wish
they had. That way, we can start with nothing, and
figure out what should go in. My druthers: I like tabbed interfaces
with fewer windows. Keyboard shortcuts for
browsing classes and methods. I’d like more powerful
searches. Searching for implementers/senders within a package, bundle,
namespace. I think much more can be done. From: Travis Griggs
[mailto: I'm going for an "original" topic to beat to death here. :) All software accrues features. Over time, it turns out that some
of the features become obsolete. Or of little enough value, that carrying them
forward is not worth the cost, because they get in the way of other things. The
"Lean" thing. There are some obvious advantages to doing so;
by vigilantly keeping your interface simple, the approachability is that
much better. So... if you could take as many as 4 (or less) things out of the
Refactoring Browser, what would they be? What are the items you look at and find
yourself saying: "Why is that still in there? I never use that? And I
would never show a newbie that." Just the Browser please. If you want to
nominate another tool to remove 4 things from, throw that at the bottom and we
can start another thread. -- Travis Griggs Objologist "It’s actually
much easier to get around on ice than it is on dry land—if you use
skates." - Paul Graham
-- -- |
AW: New Topic To Beat Into the Ground
|
|
In reply to this post by Ladislav Lenart
That's cool!
-----Ursprüngliche Nachricht----- Von: Ladislav Lenart [mailto:[hidden email]] Gesendet: Donnerstag, 22. März 2007 14:30 An: [hidden email] Cc: VWNC Betreff: Re: New Topic To Beat Into the Ground Chris Winemiller wrote: > But you can't do that when you want to highlight text within a method > (even one you have not yet accepted) and see the implementors of what > you highlighted. Well, I know this is off topic, but it might be interested for Chris and others... We enhanced paragraph editor with ability to browse Namespaces, Classes, methods (or any symbols for that matter) or references to them. The usage is simple. Let's say you have the following written in a text editor pane: someAction: anObject anObject do: #something with: self. When you place cursor inside some|Action and hit F6, new browser opens with all references to #someAction:. When you hit F7, new browser opens with all implementors of #someAction:. The same pays for symbol #something. When you place cursor inside anObj|ect and hit F7, new browser opens on Object class. When you hit F6 new browser opens with all references to Object class. It is even possible to browse multiword messages, just place cursor inside the first word of the message and hit Shift + FX. If more than one multiword messages exist in the system that start with that word, popup menu opens where you can select the appropriate one. The same mechanism works for class names as well, even with namespaces: Smalltalk.Cor|e.Object opens browser on Object class. And if you like to browse just Core namespace in the example above, simply select the Core word and hit FX. This feature is especially useful in comments, because it effectively makes them hyperlinked - you can immediately browse Classes and messages from them without need to retype their names somewhere else. Ladislav Lenart |
Re: New Topic To Beat Into the Ground
|
|
In reply to this post by Travis Griggs-3
Don't touch the hierarchy view if you're not replacing it with something better or you'll meet untimely nuclear trout attack and no conventional shield would help you. |
Re: New Topic To Beat Into the Ground
|
|
In reply to this post by Arden Thomas
a bit of quick brainstorming:
A lot of other IDEs such as Eclipse provide for a one place where all searches have been stashed for a session i.e. I would like to see an RB tab , a plugin, where I can do "advanced" searches from but also one where I can refer back to searches I had previoulsy performed including their results. In general control the Windows explosion, tabs are good -- allow for any tool to be tabbed into the general IDE, if you want to go crazy one can take on step further and provide for the notion of "dockable" UI components such as seen in the Adobe products, onto a different issue the SingleWindowSelection (sp?) package was a good start in minimizing window explosion although I would like to see a tree to follow the path of implementors and senders i.e. not just rely on the back and forwards navigation but the "history" should be depicted as a tree On Thu, 22 Mar 2007 08:45:41 -0500, Arden Thomas <[hidden email]> wrote: > Great topic. > > > I wonder if it would also be constructive at some point, to get a > consensus > on “best practices” in development and browsing. > > > What people use most, and what they wish they had. > > > That way, we can start with nothing, and figure out what should go in. > > > My druthers: > > > I like tabbed interfaces with fewer windows. > > Keyboard shortcuts for browsing classes and methods. > > I’d like more powerful searches. Searching for implementers/senders > within > a package, bundle, namespace. I think much more can be done. > > > Arden > > [hidden email] > > > > _____ > > From: Travis Griggs [mailto:[hidden email]] > Sent: Wednesday, March 21, 2007 2:25 PM > To: VW NC > Subject: New Topic To Beat Into the Ground > > > I'm going for an "original" topic to beat to death here. :) > > > All software accrues features. Over time, it turns out that some of the > features become obsolete. Or of little enough value, that carrying them > forward is not worth the cost, because they get in the way of other > things. > The "Lean" thing. There are some obvious advantages to doing so; by > vigilantly keeping your interface simple, the approachability is that > much > better. So... if you could take as many as 4 (or less) things out of the > Refactoring Browser, what would they be? What are the items you look at > and > find yourself saying: "Why is that still in there? I never use that? And > I > would never show a newbie that." Just the Browser please. If you want to > nominate another tool to remove 4 things from, throw that at the bottom > and > we can start another thread. > > > -- > > Travis Griggs > > Objologist > > "It’s actually much easier to get around on ice than it is on dry land—if > you use skates." - Paul Graham > > > > > > > > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.446 / Virus Database: 268.18.16/729 - Release Date: > 3/21/2007 > 7:52 AM > > > -- Charles A. Monteiro http://wiki.nycsmalltalk.org http://www.monteirosfusion.com http://monteirofusion.blogspot.com |
Re: FW: New Topic To Beat Into the Ground
|
|
In reply to this post by Boris Popov, DeepCove Labs (SNN)
or it can also encourage the use of large fonts :)
not being funny, larger fonts are easier on my eyes On Wed, 21 Mar 2007 14:16:57 -0500, Boris Popov <[hidden email]> wrote: > I do use 'zoom' a lot when browsing version history graph, other than > that it does nothing but encourage very long methods :) > > -Boris > -- Charles A. Monteiro http://wiki.nycsmalltalk.org http://www.monteirosfusion.com http://monteirofusion.blogspot.com |
Re: New Topic To Beat Into the Ground
|
|
In reply to this post by Travis Griggs-3
Travis:
your notion of lean may not be mine :) so one way would be to just make everything configurable and then let users somewhere check what features they want so instead of ripping out something like "hardcopy" as an example :), just make it an option in other words people work in many different ways, instead of doing some lowest common denominator thing, or imposing the majority's version of what "cool" is or worse what "right" is, I vote that you spend your time making RB just totally configuration driven , indeed then RB can be lean code wise but just gets fatter by what a particular developer may want to stuff "plug" into it. RB already has some notions of pluggability they just need to be extended. BTW, to be nice and just answer your question. I guess the one thing that I don't ever use is that "find" thing on top of the browser. I remember trying it once and it seemed to throw back something at the time totally useless or not what I wanted :) and so I just went back to looking for things my usual ways, anyhow as per my other post , its a sorry excuse for a more fully developed "advance" search plugin. my 3 cents -Charles On Wed, 21 Mar 2007 13:25:14 -0500, Travis Griggs <[hidden email]> wrote: > I'm going for an "original" topic to beat to death here. :) > > All software accrues features. Over time, it turns out that some of > the features become obsolete. Or of little enough value, that > carrying them forward is not worth the cost, because they get in the > way of other things. The "Lean" thing. There are some obvious > advantages to doing so; by vigilantly keeping your interface simple, > the approachability is that much better. So... if you could take as > many as 4 (or less) things out of the Refactoring Browser, what would > they be? What are the items you look at and find yourself saying: > "Why is that still in there? I never use that? And I would never show > a newbie that." Just the Browser please. If you want to nominate > another tool to remove 4 things from, throw that at the bottom and we > can start another thread. > > -- > Travis Griggs > Objologist > "It’s actually much easier to get around on ice than it is on dry land > —if you use skates." - Paul Graham > > -- Charles A. Monteiro http://wiki.nycsmalltalk.org http://www.monteirosfusion.com http://monteirofusion.blogspot.com |
RE: New Topic To Beat Into the Ground
|
|
In reply to this post by Travis Griggs-3
Hi Travis, I predominantly use the context sensitive
menus. Consequently... The only menu bar group I use is Find. And it’s really, really
annoying that it doesn’t have implementers/selectors as on the VisualLauncher. All the rest can go, except possibly for
View. I may use View, now I know what it does! I
tried it once, and nothing seemed to happen, so I ignored it. It would be very
useful if upon creation of a view if a new Tab in the notebook is added. (Please
don’t slap me with a trout!). That way it’s obvious and you don’t
have to drop down a menu. I don’t use any of the tool bar, that can go. I don’t use the hierarchy diagram, nor Code Critic. I would possibly use Rewrite, if I could
figure out how to. I’m not using Store as yet, so I’m
currently Parcel orientated. Nevertheless I do maintain parallel Packages, as
the RuntimePackager works on those. HTH, Stewart More trout stuff… I like the way VA works when you pop up a
menu on a selection. You can go directly to implementers/selectors browse class
etc I like VA’s
multi line indent function – is there a goodie
for this in VW? -----Original Message----- I'm going for an "original" topic to beat to death here. :) All software accrues features. Over time, it turns out that some
of the features become obsolete. Or of little enough value, that carrying them
forward is not worth the cost, because they get in the way of other things. The
"Lean" thing. There are some obvious advantages to doing so;
by vigilantly keeping your interface simple, the approachability is that
much better. So... if you could take as many as 4 (or less) things out of the
Refactoring Browser, what would they be? What are the items you look at and find
yourself saying: "Why is that still in there? I never use that? And I
would never show a newbie that." Just the Browser please. If you want to
nominate another tool to remove 4 things from, throw that at the bottom and we
can start another thread. -- Travis Griggs Objologist "It’s
actually much easier to get around on ice than it is on dry land—if
you use skates." - Paul Graham
|
Re: New Topic To Beat Into the Ground
|
|
In reply to this post by Travis Griggs-3
There is a good reason to keep items in menu bar menus even if most people access them via context menus in list views. If you need special screen scraping support for visually impaired people, like braille output, it will be hard to navigate to context menus, but a lot easier to use menu bars where the entries are always at the same position. I once worked in a project which had to support people with different kinds of visual impairments, and it was e.g. *very* important to carefully align all the widgets at defined positions, with equal spacings, and make sure that every function of the software could be found at easily accessible, well defined positions. VisualWorks probably isn't fun for someone needing braille output anyway, but there's no need to make it harder than it is.
> Dennis Smith wrote: I don't really see any reason toduplicate > things in right-click in the menu. > > This is "standard" in almost all operating systems. Right-click > isconsidered a shortcut and narrower selection of items for > convenienceonly. At least for the views taking over the role of the > "main" editorthing. Joachim Geidel |
Re: New Topic To Beat Into the Ground
|
|
In reply to this post by Charles A. Monteiro-2
> BTW, to be nice and just answer your question. I guess the one thing
> that I don't ever use is that "find" thing on top of the browser. I > remember trying it once and it seemed to throw back something at the > time totally useless or not what I wanted :) and so I just went back > to looking for things my usual ways, [...] > This is a sign that your images are too small ;-) If your number of packages goes towards 1000 you will *really* want to use find to do navigation - scrolling-and-clicking is simply way too cumbersome. In fact we just added another find box in the top of the packages pane to aid in navigating through package names... R - |
| Free forum by Nabble | Edit this page |