Richard Frith-Macdonald wrote:
On 17 Oct 2009, at 00:01, Wolfgang Lux wrote:
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 consider Gnome to be similar enough to Windows in its feel (though
not in its look) to warrant a behavior akin to Windows for it.
[...]
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).
Well, it is certainly not what *I* would expect from a hide
application command in a Gnome or KDE environment; but then, I'm
using GNUstep primarily with Apple's quartz-wm on OS X and with
WindowMaker on other platforms and therefore do not care much. I
mainly opposed to your proposal because it appeared to me as
introducing more brittle code in -back, which I would like to see
avoided, but your actual change is not of that sort and so it is okay
for me.
Wolfgang
P.S.: I just saw in the commit logs that you added a new library
license to the svn tree, but made it impossible to check this out for
us who are using a less capable operating system (OS X), which uses a
case-insensitive file system by default. Please, never use files like
License.m and license.m, whose names differ only in their case, in
the same directory.
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev