User interface

[ben_josephs]

I'm not sure how, as potential users of WildEdit, we should be evaluating it. Is it intended to be a finished tool in its own right, or more an indication of functionality that may be incorporated into a future version of TextPad? If it is the latter, I don't want to waste too much time raising user interface issues, as opposed to functionality issues. But I feel compelled to say that I find the GUI rather clunky...

I find the two-level structure of the WildEdit window, with tabbed panes, awkward. I would like to see my options together, instead of split arbitrarily between the "Replace" and "Options" panes. My brain/fingers find it clumsy to have to type <Ctrl-1> and the like and then <Alt-R> or whatever. (And they play the piano.) And, perversely, you can't <Ctrl-PgUp> or <Ctrl-PgDn> between the top and bottom halves of the window.

As mentioned in the help file, the meaning of some keyboard actions depends on where keyboard focus is, even within one window; it's behaving modally. Thus <Alt+F> may be a shortcut for "Find what:" or for "File", and <Alt+E> may be a shortcut for "Character encoding:" or for "Edit". If focus is in the "Replace" area, you have to remember to type <Alt> <F> (not <Alt+F>) for "File", and <Alt> <E> (not <Alt+E>) for "Edit". And <tab> behaves differently in the "Replace" and "Test" panes.

What happened to <Ctrl-3> and <Ctrl-4>?

Could we be not be given the power to change the shortcuts to our own perverse preferences?

We can change the font size through the GUI, but not its face. For this we have to edit config.xml by hand.

I have some wide and deep development directory structures. They take a long time to display in the tree view, and this holds up the start of the application. Can the display of the fully expanded tree view be made optional? I would prefer not see the contents of the parent directory if I haven't asked to see it.

It's a useful tool, but needs some polishing.

[bbadmin]

My advice would be simply to evaluate WildEdit against your requirements, and decide if it does the job, cost effectively.

Which options do you need to keep changing? We assumed that they would be customised to requirements, and then forgotten about.

We used the standard Windows shortcuts, for navigation: F6/Shift+F6 to cycle forwards/backwards through the 3 main panes and Ctrl+Page Up/Down to cycle forwards/backwards through the tabs within a pane. The commands on the View menu and their corresponding shortcuts, allow you to jump straight to a particular tab in a pane. We may implement customisation of these shortcuts in a future release.

Keith MacDonald
Helios Software Solutions

[ben_josephs]

Thanks for your response.

I reckon UKP 9.99 inc. VAT is pretty cost effective for the functionality provided. About four pints. Perhaps I'll do without the four pints. :-)

I suspect that I might often change at least the '.' does not match a newline character and Match file names with a regular expression options (and possibly the Use POSIX extended, rather than ECMAScript syntax and rules option).

But that's just my preference, and there's the point. Each user has a different way of working, and any arbitrary separation of related things is certain to upset some of them. It's not as if there were a vast array of options, as in, say, Visual Studio.

It's primarily the two-level arrangement that I find awkward. I find it inconvenient that I can't see two related controls at the same time, and cumbersome that I have to use two shortcuts to navigate from one to the other. For example, the '.' doesn't match '\n' option is closely related to the search expression, but I can't see the control for one while I'm looking at the control for the other. And to navigate from one to the other I have to type two shortcuts. Well, possibly two, but I can't see whether I need the second until I've typed the first.

[Thomas Schremser]

Another interface issue albeit not a critical one:

The white color is hardcoded which looks pretty ugly under Win2k especially if one is using an other color as white as window background. Therefore in the Treeview it should have window background color and on the tabs button face color.

[asherber]

Yes, I agree about the color. Also, the panes have too much beveling. The treeview pane has one bevel, and the panes on the right have two bevels (probably one for the whole right side and then one for each sub-pane). If you look, for example, at Windows Explorer, the panes have no beveling at all.

These are small details, but I have a real aversion to apps -- even incredibly useful ones, like this -- which look cheaply done.

[rkiesler]

Whenever I perform operations on files located elsewhere on the network, the treeview pane constantly re-paints itself. Other than the bothersome visual effect, this is probably a waste of resources.

--
Roy