From: Berthold <b.t...@gm...> - 2003-05-19 11:36:52
|
Hi all, Peter, wouldn't it be nice, if the "X"-button in upper right corner (to close sp= litted windows) was able to close the active file anyway? I use version 0.18.1.14. The button is only "active" on splitted windows. --=20 Viele Gr=FC=DFe Berthold |
From: Peter G. <pe...@ar...> - 2003-05-19 13:05:45
|
> wouldn't it be nice, if the "X"-button in upper right corner (to > close splitted windows) was able to close the active file anyway? I believe I suggested that once myself, but the suggestion was reviewed by the design committee and rejected ("it might confuse the user"). Ctrl W is your friend. -Peter |
From: Berthold <b.t...@gm...> - 2003-05-20 09:06:51
|
Hi, what about controlling this in the prefs? It is confusing ME that it is only active on splitted windows... What about the ability to split windows verticaly? Am 05/19/03 03:06 PM schrieb Peter Graves: >>wouldn't it be nice, if the "X"-button in upper right corner (to >>close splitted windows) was able to close the active file anyway? >=20 >=20 > I believe I suggested that once myself, but the suggestion was reviewed > by the design committee and rejected ("it might confuse the user"). >=20 > Ctrl W is your friend. >=20 > -Peter --=20 Viele Gr=FC=DFe Berthold |
From: Peter G. <pe...@ar...> - 2003-05-20 14:53:23
|
> what about controlling this in the prefs? > It is confusing ME that it is only active on splitted windows... Well, you're welcome to submit a patch... ;) > What about the ability to split windows verticaly? This is not currently supported, but it's probably a good idea. |
From: Mikol G. <mi...@th...> - 2003-05-20 19:49:34
|
Before we get too far down this path, let's make sure that we address the real issue, which I take to be the following: The expected behavior for a close button associated with a buffer is to close the current buffer, not unsplit the window. Historically, however, the close button has been used to unsplit the window since need a convenient and obvious way to escape from automagically split windows (as for list matching occurances), or even from windows that they split themselves. I think that these two uses are at odds and should -not- be overloaded on the same control (even if modally via some pref). Consider, for example, that someone may expect to be able to close a buffer without unsplitting the window. Or that when closing buffers is the default behavior, that unsplitting windows may not be discoverable. I think that we probably need two buttons if we want to address both cases. The current X (especially in it's current position) is arguably more correct for closing buffers than for unsplitting windows, which begs the question of what form the second button will take. In fact, it may be prudent to develop a framework for managing split windows graphically. Maybe we need three or four buttons for splitting (horizontally and vertically) and unsplitting. In any case, I would not overload the current control with two conflicting behaviors. m > > what about controlling this in the prefs? > > It is confusing ME that it is only active on splitted windows... > > Well, you're welcome to submit a patch... ;) > > > What about the ability to split windows verticaly? > > This is not currently supported, but it's probably a good idea. > > > ------------------------------------------------------- > This SF.net email is sponsored by: ObjectStore. > If flattening out C++ or Java code to make your application fit in a > relational database is painful, don't do it! Check out ObjectStore. > Now part of Progress Software. http://www.objectstore.net/sourceforge > _______________________________________________ > armedbear-j-devel mailing list > arm...@li... > https://lists.sourceforge.net/lists/listinfo/armedbear-j-devel -- MEE kle |
From: Peter G. <pe...@ar...> - 2003-05-20 19:42:52
|
> In any case, I would not overload the current control with two > conflicting behaviors. Yeah, I think this is the key point. I'm open to suggestion on how split windows should be managed, since I don't think the current implementation has exactly the right feel (although it's not a complete disaster either). Kate (which I happened to be looking at this morning) uses three buttons on its main toolbar ("split horizontally", "split vertically" and "close current"). This is fine, but j lets you turn off the toolbar (it appears that kate does not let you do this), and the 'x' in the j's location bar is still available when the main toolbar is gone, which is a good thing. There could be more buffer- and/or window-specific buttons in the same area where the 'x' now is, but that's really a graphic design project (some cool small icons would be required); the coding part of is it trivial. The 'x' is an example of my best achievement so far in the area of graphic design, and I needed help for that... ;) -Peter |
From: Ludovico M. <lu...@as...> - 2003-05-21 10:48:42
|
Maybe it's a dumb suggestion, but why don't you let windows be split/joined via the frame border, like PythonWin does (and Word for Windows too, in a more sophisticated manner)? Put a visible editor frame below the file name, and drag it to split/unsplit/resize etc. Ludo |
From: Peter G. <pe...@ar...> - 2003-05-21 15:24:07
|
On Wed, 21 May 2003 at 12:48:29 +0200 (CEST), Ludovico Magnocavallo wrote: > Maybe it's a dumb suggestion, but why don't you let windows be > split/joined via the frame border, like PythonWin does (and Word for > Windows too, in a more sophisticated manner)? > > Put a visible editor frame below the file name, and drag it to > split/unsplit/resize etc. Well, dragging is a slow, hand-intensive operation. Splitting windows or closing them needs to be quick and easy, even if you do it with the mouse... -Peter |