On 17 Oct 2009, at 00:01, Wolfgang Lux wrote:
Richard Frith-Macdonald wrote:
On 16 Oct 2009, at 19:16, Wolfgang Lux wrote:
IMHO Richard's proposal is much too complicated. I'd suggest
something
radically simpler: If an application does not have an appicon the
hide
command should just minimize all application windows. As far as I
understand this also was the solution used by Apple in OpenStep
4.2 for
Windows. See, e.g., http://support.apple.com/kb/TA45871 and search
for
the term "hide" (with quotation marks) in that document. This can be
implemented trivially with the three-line patch below in
NSApplication.m.
Good idea, but unfortunately that approach does not really work and
is not really that simple:
1. the app is not properly hidden ... there are potentially loads
of miniwindows left visible
2. the app is potentially 'lost' (as at present) if it has no
windows (and hence no miniwindows)
3. there is no consideration of unhiding ... allowing for that
would require a lot more code (to track which windows were
miniaturised as part of the hide process, and automatically
deminiaturise them when you click on any of the miniwindows of the
'hidden' app).
Problem (2) is the problem we currently have ... so this approach
actually adds an issue (1) without solving the original issue.
You are right with issue (1), but this is only for the case where an
application
deliberately hides its appicon. On the other hand, in Phillipe's
case I feel that
GSSupressAppIcon is abused (somewhat) as a workaround for the lack
of better
integration with the foreign environment. Maybe it would be a better
idea to make
use of the current interface style instead of checking the
_app_icon_window
attribute. Then, assuming that, e.g., an interface style
NSWindows95InterfaceStyle
indicates the presence of a taskbar, the application should suppress
its appicon
*and* not manage any miniwindows on itself. Thus, problem (1) would
go away.
With respect to problem (2), I think that this could be handled by
terminating
applications by default when their last window is closed and the
application
delegate does not respond to -
applicationShouldTerminateAfterLastWindowClosed:.
It sounds reasonable to allow interface style to control that sort of
thing, and the behavior you suggest makes sense for a windows app.
I'm not sure it addresses the original case though ... which was not
for an app running on windows and where, specifically, we know we
don't want to have the app close when the last window closes. So we
probably still need to retain defaults for more fine grained control
over behavior rather than just forcing a microsoft style behavior.
It's not a problem really to do both microsoft style behaviors and
user defaults for fine control.
I see issue (3) as rather unproblematic. If the app is properly
hidden, the user
cannot invoke -unhide: in the first place except by selecting the
Show All menu
command from another GNUstep application.
We could simply ignore this request
since the native applications of the foreign gui environment do not
understand
that request and we would at least be consistent with our environment.
Well, *normally* (for us) you can unhide by clicking the app icon, and
*normally* in other environments there is a way to select/activate an
application easily/quickly. I think, form a usability point of view
it's desirable to keep that somehow and it's what my proposal was
trying to do (and I think it's what Philippe as asking for.
But even if you are not happy with that suggestion, I'd really
prefer to add the
additional flag to every window that would allow distinguishing
whether a window
was miniaturized or "hidden" than to delve into the hairy
interaction with lots
of different window managers out there and trying to convince them
to manage the
offscreen appicon.
In my opinion back is already bloated too much with conditional
code that is supposed to work with WindowMaker, KDE, Gnome, and
whats not. Yet,
it nevertheless does not really work with, e.g., Apple's quartz-wm
(Apple managed
to implement the NETWM specification in completely weird ways, but
that is a
different story).
I don't really want to do lots of window manager specific code either
(well, keep it to a minimum anyway), but it's one of our official
stated aims to integrate well into other environments, so I expect
some of it will be inevitable. However, my proposal was to avoid it
as much as possible by using existing mechanisms.
1. keep the app icon but hide it if it's 'suppressed' (I changed
NSApplication to do that)
2. (a) use the existing code for window managers to handle
miniaturised windows to provide a handle to unhide the application, or
(b) if the 'native' window manager has another unhide mechanism, use
that.
Maybe the change (1) is sufficient for Philippe though ... if you hide
an app which has the icon suppressed, the icon is shown so that you
can click on it to unhide again.
Implementing 2(a) would not require any additional backend work ... it
would just leverage the existing minwindow code.
Implementing 2(b) would be the messy option,but it may not be needed
for most environments ... and where environments do require us to
adopt their conventions for hiding/unhiding, we really do need to do
that rather than just having a miniatuires/deminiaturise option to
avoid the issue.
Of course, in some environments the behavior you select would actually
be the native behavior ... in which case we would presumably want to
adopt that there and remove the 'hide' menu item.
Anyway ... see what you think of the change to allow unhide by showing
the app icon when the app is hidden, and think about how it would be
if, instead of showing that, what we actually did was show a
miniaturised version displayed in whatever way the window manager
normally handles miniaturised windows (eg in a task bar).
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
