[vlc-devel] Fwd: VLC Mac OS X interface question

[Derk-Jan Hartman]

---------------------------- Original Message ----------------------------
Subject: VLC Mac OS X interface question
From:    "Matthew Klahn" <mklahn at codetek.com>
Date:    Thu, February 5, 2004 19:18
To:      hartman at videolan.org
--------------------------------------------------------------------------

Hi, Dirk-Jan.

My name is Matthew Klahn and I'm a software architect here at CodeTek 
Studios, Inc. We've currently got a compatibility issue with your VLC 
application that we've researched and I wanted to mention to you. Since 
your email address is at the top of the source file that I've been 
looking at, and you are noted on the videolan.org page as the person  who
maintains the Mac OS X interface, I thought you would be the best  person
to contact. If this is not correct, and I should contact someone  else,
can you please let me know who I should contact?

Our CodeTek VirtualDesktop product patches other applciations running  on
Mac OS X in order to get information about and manipulate that 
application's windows. In the case of VLC, we see that the application  is
a Cocoa application, and we are able to do some extra things that  are
only possible in Cocoa apps. However, we do make use of some of the  Cocoa
NSApplication resources, such as the autorelease pool in our  patch. This
is where you (I believe) come in, since the compatibility  issue that
we're having deals with the Mac OS X interface code.

I've read through (a very small subset of) the Mac OS X interface code 
for VLC, and I've noticed something that might be improved upon, but  I'm
not sure because I am probably not aware of all the reasons why the  code
works the way it does. In modules/gui/macosx/intf.m, I have found  the
code that deals with the NSApplication delegate that you have, and  the
initialization code for the application. In the OpenIntf()
implementation, I see that you instantiate an NSAutoreleasePool and  store
it in the intf_thread_t structure, p_intf, then instantiate the  shared
application for your NSApplication subclass (which will now use  the
NSAutoreleasePool that you've just instantiated), and autorelease  the
shared application. In the CloseIntf() implementation, when you're 
cleaning up the process, you release the autorelease pool so that it  can
clean up all autoreleased objects. The terminate: method for  your 
NSApplication subclass, VLCApplication, sets an internal stateflag so 
that eventually will break out of the while loop in manage().

Here's where I think it may be possible to make a few changes that will 
not only solve the compatibility issue with our product, but also make 
your code a bit simpler and easier to maintain. Let me ask a couple of 
questions, first:

1) Is it necessary to autorelease the VLCApplication's
sharedApplication? In a normal, nib-based application, this would not  be
the standard way to ensure that the application is cleaned up
properly. However, you may have some need outside of the NSApplication 
that makes it necessary to do this. When you release the
NSAutoreleasePool (either in CloseIntf() or after the while loop in 
manage() exits) that you create in OpenIntf(), the NSApplication will  get
cleaned up, freeing all the resources of the parent NSApplication  class.
Now, this causes CTVD Pro problems, because we don't expect the 
autorelease pool to go away before our cleanup code is called, which 
happens in VLC because of that autorelease.

2) You have terminate: setting the b_die flag, and then you call [self 
terminate] after the b_die flag breaks you out of the while loop in 
manage(). Because you never call the superclass terminate:, some
termination procedures (like sending out the applicationShouldTerminate 
and applicationWillTerminate notifications) will never be done. While 
this doesn't affect our product directly, this doesn't seem like the 
behavior you would want. Was it intentional to bypass calling the base 
class's terminate:?

I would love to talk to you about this code, and suggest patches that 
could make your initialization and deallocation procedures a little 
cleaner and easier to maintain. If you would like to talk about this, 
please let me know. I also wonder if it would be possible for you to  not
autorelease the shared application, because of the compatibility  issue
that this creates with CTVD Pro. If you don't have an overriding  reason
why that is being autoreleased, it most likely would be harmless  to not
autorelease it, but rather call terminate: on the superclass so  that all
resources are cleaned up before exit.

Please let me know. If you'd like to use AIM instead of email for 
communications, please let me know, and I can give you my AIM address.

--
Matthew S. Klahn
Software Architect, CodeTek Studios, Inc.
http://www.codetek.com



-- 
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://developers.videolan.org/lists.html
If you are in trouble, please contact <postmaster at videolan.org>