[MonoDevelop] Quick finder discussion
m.j.hutchinson at gmail.com
Fri Nov 27 02:02:53 EST 2009
On Thu, Nov 26, 2009 at 4:06 AM, Mike Krüger <mkrueger at novell.com> wrote:
> I need some opinions on our 'quick finder'. I want to improve the class
> quick finder.
> It has some issues:
> + It takes up too much screen space
> + It could contain some more functionalaty (think of toolbar buttons)
I definitely agree that we could add some more buttons to make it more
useful, and make it take less vertical space. Right now I hide it,
because I just don't find it useful.
> XCode has a very nice 'quick finder' - see the screenshots in:
> What I find nice is that it merges the 'notebook' and the class quick
> finder. Xcode doesn't have a notebook for multiple open files instead
> files can be switched with a drop down (prev/next file buttons are at
> the left).
> The question is - should we do that too? The benefit is that we save
> screen space and it'll look very clean. The downside is that switching
> files is more than just 'one click' and that's no longer possible to
> quickly see all open files (but I think every developer knows what files
> he was opening :)).
I would be strongly against making the file-combo change right now,
for a number of reasons:
* Tabs are very familiar to our users and users of most other IDEs,
and also very familiar to any new user who's used a modern web
* Tabs can be re-ordered, and potentially dragged off and re-docked at
the side, or left floating on another monitor. None of these are
possible with the combobox.
* Having a list of all open files is useful - for example, you can see
at a glance which files are dirty.
* MD uses a dock/pad workspace model like VS, Xcode uses a
floating-window workspace model, so for Xcode a window represents a
single document, and the combo is a way to switch the document.
Because the workspace models are different, workspace-related things
like this may not transfer over easily and still be usable.
Perhaps we can figure out a way to make it work well in MD, but I
think we have many other priorities that would be more useful to our
More information about the Monodevelop-list