Stupid Cocoa Question: Do I need Interface Builder?
-
If I'm developing a UI for a Cocoa app, do I need to use Interface Builder
or can I define the UI in code? The app I'm planing would use Cocoa UI
elements with some custom Java UI elements. Or even the other way around,
say I have a Java app that I want to add a new element for Mac OS X users
that is Cocoa based. If I don't use Interface Builder can you build a UI
that can use a mix of Cocoa and Swing UI elements without writing
Obective-C? Thanks.
Ryan-
+-----------------------------------------+
Ryan J. McDonough
http://www.randomthought.org
mailto:<ryan...>
+-----------------------------------------+ -
>> No. You can define the UI in the code - but this means more work for
>> you, much more work...;-)
>
> But with that said, could I mix Cocoa and Swing elements?
I don't know - but why would you like to do that at all?
cheers, Phil
--
Philippe C.D. Robert | Senior Developer
http://www.groupville.com - GroupWare made easy! -
I agree with Phil: why do you want to do that? are there some missing UI
Elements in Cocoa that force you to us Swing?
Anyway, to answer your question. Yes you could potentially use Cocoa without
Interface Builder but once again why?
As far as mixing Cocoa and Swing the problem is not IB but the fact that
Java on MacOS X is built on top of Carbon and it is not currently possible
to embed a Carbon control in a Cocoa App. This will definitely be fixed at
one point. So not using IB is not going to allow you to mix Swing and Cocoa
anyway.
----------------------------------
Henri Lamiraux
Engineering Manager
User Interface Tools Group
Apple
<lamiraux...>> From: "Philippe C.D. Robert" <phr...>
> Date: Tue, 23 Jan 2001 14:53:57 +0100
> To: "Ryan J. McDonough" <ryan...>
> Cc: <macosx-dev...>
> Subject: Re: Stupid Cocoa Question: Do I need Interface Builder?
>
>>> No. You can define the UI in the code - but this means more work for
>>> you, much more work...;-)
>>
>> But with that said, could I mix Cocoa and Swing elements?
>
> I don't know - but why would you like to do that at all?
>
> cheers, Phil
>
> --
> Philippe C.D. Robert | Senior Developer
> http://www.groupville.com - GroupWare made easy!
> _______________________________________________
> MacOSX-dev mailing list
> <MacOSX-dev...>
> http://www.omnigroup.com/mailman/listinfo/macosx-dev
> -
Henri Lamiraux wrote :> I agree with Phil: why do you want to do that? are there some missing UI
> Elements in Cocoa that force you to us Swing?
>
> Anyway, to answer your question. Yes you could potentially use Cocoa without
> Interface Builder but once again why?
>
[I jump in...] On my own project, three reasons:
1) constructing some interface dynamically, for instance having a data driven interface generated at run-time. IB is great but you can only use it to specify the static parts of the interface (by static, I mean the parts that are known at design time).
2) make it easier to port to GNUstep.
3) not having incompatibilities when moving to new versions of Cocoa. From experience, the nib format tend to change much more than the API, and you have to take manual steps to update (not much to do but boring, like opening all the nibs and saving. Next change will be to go from binary to XML).
I would say reason 1 is really the most interesting, cause it apply quite frequently.
Reason 2 is for people interested in porting to GNUstep and reason 3 is not a good reason in itself (since IB gives you so much productivity) but just a colateral benefit.
BTW, AppKit is the easier and most powerfull GUI framework I know for programatically generating interfaces. A real pleasure to work with, taking full avantage of Obj-C dynamic features. Nothing in common with MFC or Motif, and much better than Swing.
Philippe Mougin -
On Tuesday, January 23, 2001, at 04:53 PM, Philippe Mougin wrote:>
> Henri Lamiraux wrote :
>
>> I agree with Phil: why do you want to do that? are there some missing UI
>> Elements in Cocoa that force you to us Swing?
>>
>> Anyway, to answer your question. Yes you could potentially use Cocoa without
>> Interface Builder but once again why?
>>
>
> [I jump in...] On my own project, three reasons:
>
> 1) constructing some interface dynamically, for instance having a data driven interface
> generated at run-time. IB is great but you can only use it to specify the static parts of the
> interface (by static, I mean the parts that are known at design time).
>
Not true at all.. you can programatically create and add/remove items in your UI without any problems using Cocoa. Nothing static there at all.> 2) make it easier to port to GNUstep.
>
> 3) not having incompatibilities when moving to new versions of Cocoa. From experience,
> the nib format tend to change much more than the API, and you have to take manual steps to
> update (not much to do but boring, like opening all the nibs and saving. Next change will be
> to go from binary to XML).
>
???? I have .nibs that still load fine from 3.x. True, the UI stuff has changed some, but that isn't a programmatic issue at all. It is an issue with the UI, but not nibs. The same problem exists on Carbon apps. The UI has been in much more flux than it has been, ever.> I would say reason 1 is really the most interesting, cause it apply quite frequently.
> Reason 2 is for people interested in porting to GNUstep and reason 3 is not a good reason in
> itself (since IB gives you so much productivity) but just a colateral benefit.
Well, 1 isn't true, you can easily add stuff to your UI without using IB.
2. Isn't Apple's concern (can you even program GNUSTEP from Java?
3. isn't any sort of an issue either. This isn't a nib format, but rather a UI issue. And as soon as the UI stablizes (1.0) then it won't be an issue either.> BTW, AppKit is the easier and most powerfull GUI framework I know for programatically
> generating interfaces. A real pleasure to work with, taking full avantage of Obj-C
> dynamic features. Nothing in common with MFC or Motif, and much better than Swing.
>
> Philippe Mougin
> _______________________________________________
> MacOSX-dev mailing list
> <MacOSX-dev...>
> http://www.omnigroup.com/mailman/listinfo/macosx-dev
> -
Scott Anguish wrote:> Not true at all.. you can programatically create and add/remove items in your UI without any problems using Cocoa. Nothing static there at all.
I would guess he was referring to sth like XUL/WO. Eg containing a
repetition which creates a set of UI objects.> Well, 1 isn't true, you can easily add stuff to your UI without using IB.
> 2. Isn't Apple's concern (can you even program GNUSTEP from Java?
Yes, you can. There is a GNUstep Java-ObjC bridge.
Greetings
Helge
--
SKYRIX Software AG http://www.skyrix.com/
Join the team: http://www.skyrix.com/de/jobs/index.html -
At 01:23 +0100 24/01/01, Helge Hess wrote:> Yes, you can. There is a GNUstep Java-ObjC bridge.
And where does this work ?
I mean which VMs, which platforms ??
Paul -
> Scott Anguish wrote:
>> Not true at all.. you can programatically create and add/remove items in your UI without any problems using Cocoa. Nothing static there at all.
>
> I would guess he was referring to sth like XUL/WO. Eg containing a
> repetition which creates a set of UI objects.
>
Not at all. I have several times taken a base view I have designed within IB and then dynamically
added and subtracted sub-views depending on the size of the window or selected options. Dynamic
creation of the interface at run time is very simple. But I still use IB as a starting point.
Steven Noyes
NoiseTECH -
On Tuesday, January 23, 2001, at 11:47 PM, Scott Anguish wrote:> 2. Isn't Apple's concern (can you even program GNUSTEP from Java?
YES. -
Hi,
I think it requires a Java 2 JVM for weak references. I tried it on
Linux, but it should work on any JNI platform as well (at least the Unix
ones).
Greetings
Helge
Paul Libbrecht wrote:>
> At 01:23 +0100 24/01/01, Helge Hess wrote:
>> Yes, you can. There is a GNUstep Java-ObjC bridge.
>
> And where does this work ?
> I mean which VMs, which platforms ??
>
> Paul
--
SKYRIX Software AG http://www.skyrix.com/
Join the team: http://www.skyrix.com/de/jobs/index.html -
Scott Anguish wrote :>
> On Tuesday, January 23, 2001, at 04:53 PM, Philippe Mougin wrote:
>
>>
>> Henri Lamiraux wrote :
>>
>>> I agree with Phil: why do you want to do that? are there some missing UI
>>> Elements in Cocoa that force you to us Swing?
>>>
>>> Anyway, to answer your question. Yes you could potentially use Cocoa without
>>> Interface Builder but once again why?
>>>
>>
>> [I jump in...] On my own project, three reasons:
>>
>> 1) constructing some interface dynamically, for instance having a data driven
> interface
>> generated at run-time. IB is great but you can only use it to specify the static parts of the
>> interface (by static, I mean the parts that are known at design time).
>>
>
> Not true at all.. you can programatically create and add/remove items in your UI without
> any problems using Cocoa. Nothing static there at all.
>
Sorry, my comment was not clear and really misleading. Actually I was not referring to Java/Swing at all but only to the second question raised by Henri: " Yes you could potentially use Cocoa without Interface Builder but once again why ?" in response to the original question of Ryan: "If I'm developing a UI for a Cocoa app, do I need to use Interface Builder
or can I define the UI in code ?"
In this context, I'm sure we all agree: one can define the UI in code using the AppKit API, without using IB. Moreover, in some situations, it becomes mandatory (to resort to AppKit coding) because there are some things you can't do with IB, like dynamically creating or modifying the interface at run-time.>> 2) make it easier to port to GNUstep.
>>
Let me clarify: Today, the GNUstep support for nib files is far from optimal (the GNUstep Interface Builder is not yet functional and the nib to gmodel translator is not complete and I think don't work yet for OSX PB nib files). So you are in a better position to support the GNUstep platform if you have all your UI stuff in your code (using AppKit) instead of in nib files.>> 3) not having incompatibilities when moving to new versions of Cocoa. From experience,
>> the nib format tend to change much more than the API, and you have to take manual steps to
>> update (not much to do but boring, like opening all the nibs and saving. Next change will be
>> to go from binary to XML).
>>
>
> ???? I have .nibs that still load fine from 3.x. True, the UI stuff has changed some, but
> that isn't a programmatic issue at all. It is an issue with the UI, but not nibs. The same
> problem exists on Carbon apps. The UI has been in much more flux than it has been, ever.
My experience moving nib files to various new versions on their various new supported platforms (including NeXT, Sparc and Windows NT) seems to have been a little bit more painful than yours, due to differences in the internal nib format (see for example the release note: "Loading NEXTSTEP 3.x .nib Files" in the DP4 notes) or graphical differences. Anyway, as I said before, this is not a big issue in itself.> [...]
> can you even program GNUSTEP from Java?
As other have already said, you can do that. It's called JIGS (Java Interface for GNUstep) and allows you to use GNUstep from Java or java from ObjC.
Philippe -
On Wednesday, January 24, 2001, at 12:35 PM, Philippe Mougin wrote:> Let me clarify: Today, the GNUstep support for nib files is far from optimal (the GNUstep
> Interface Builder is not yet functional and the nib to gmodel translator is not complete
> and I think don't work yet for OSX PB nib files). So you are in a better position to support the
> GNUstep platform if you have all your UI stuff in your code (using AppKit) instead of in nib
> files.
It is not easy for complex interfaces... My solution was to make my nibs again on an older platform (YellowBox, Rhapsody...) and convert them to gmodels. And that worked quite well (I still had to change some colors by hand).
For nib2gmodel on OSXPB, I tried it. Well, it converts the files to gmodels, but I believe some of the new features of the nibs are not well translated and makes the gmodels not usable.
Raphael -
> I agree with Phil: why do you want to do that? are there some missing UI
> Elements in Cocoa that force you to us Swing?
The element I'm looking to us is not a swing element, but the JEditTextArea
from the jEdit Text Editor. The Text Area and syntax highlighting are
contained in a separate object. Another Java text editor, Jext, is using the
JEditText area along with it's out standing syntax highlighting and bracket
matching. My plan was to us this control inside a Cocoa UI. While jEdit
works wonderfully with the Aqua look-n-feel, it doesn't function very Mac
like.> Anyway, to answer your question. Yes you could potentially use Cocoa without
> Interface Builder but once again why?
In addition to what I mentioned above, there is also another item I'd be
interested in embedding into a Cocoa app and that would be Mozilla. Some of
may or may not know that Mozilla can be embedded in Java applications:
http://www.mozilla.org/projects/blackwood/
The nice thing about the webclient is that it does not have that horrific
XUL based interface. There have even been some rumblings about using native
UI widgets for form elements in the embedded Mozilla. With Java hooks into
Mozilla and to use Java to build Cocoa applications, it lead me to believe
that perhaps one might be able to embed Mozilla into a Cocoa app using the
Blackwood Java API's and not having to use Swing. And without having to
learn Object C.> As far as mixing Cocoa and Swing the problem is not IB but the fact that
> Java on MacOS X is built on top of Carbon and it is not currently possible
> to embed a Carbon control in a Cocoa App. This will definitely be fixed at
> one point. So not using IB is not going to allow you to mix Swing and Cocoa
> anyway.
So basically I see what you're saying. Even if Java weren't involved, one
couldn't embed Mozilla into a Cocoa app just yet since it is a Carbon app.
Ryan-
+-----------------------------------------+
Ryan J. McDonough
http://www.randomthought.org
mailto:<ryan...>
+-----------------------------------------+ -
Ryan J. McDonough,> While jEdit
> works wonderfully with the Aqua look-n-feel, it doesn't function very Mac
> like.
Hmm, I think JShell (no I am not a representative of nor a paid employee of
JShell), includes some Mac JEdit plugins.
I'm still trying to get Luca's Classic LookAndFeel working for JEdit myself.
Mike Hall <mikehall...>
<http://www.spacestar.net/users/mikehall> -
on 1/23/01 5:19 AM, Ryan J. McDonough at <ryan...> wrote:> If I'm developing a UI for a Cocoa app, do I need to use Interface Builder
> or can I define the UI in code? The app I'm planing would use Cocoa UI
> elements with some custom Java UI elements.
You can certainly create new UI elements in Java with Cocoa APIs.> Or even the other way around,
> say I have a Java app that I want to add a new element for Mac OS X users
> that is Cocoa based. If I don't use Interface Builder can you build a UI
> that can use a mix of Cocoa and Swing UI elements without writing
> Obective-C? Thanks.
You cannot mix Cocoa and Swing (or AWT, in general) UI elements in the same
app. Someday, perhaps, but certainly not for X GM.
Dave -
Oh but !!
That is a sad commitment: that means there will be no applets running for OmniWeb, or do I mistake ?? Or any other of these mixes... this is really, really sad.
Is this war of incompatibility between Carbon and Cocoa going to last really long ?? This applet integration, was to me, a youth statement. If you say so for GM... I'll go to be a bit depressed...
On Wednesday, January 24, 2001, at 05:35 PM, David Ewing wrote:>
> You cannot mix Cocoa and Swing (or AWT, in general) UI elements in the same
> app. Someday, perhaps, but certainly not for X GM.
>
> Dave -
>> As far as mixing Cocoa and Swing the problem is not IB but the fact that
>> Java on MacOS X is built on top of Carbon and it is not currently possible
>> to embed a Carbon control in a Cocoa App. This will definitely be fixed at
>> one point. So not using IB is not going to allow you to mix Swing and Cocoa
>> anyway.
>
> So basically I see what you're saying. Even if Java weren't involved, one
> couldn't embed Mozilla into a Cocoa app just yet since it is a Carbon app.
Yes and no. :)
No, you probably can't drop the Mozilla engine into a Cocoa app without a
bit of work. The part of the engine that has platform-specific variants
comes Carbon and Java flavors; and Carbon views (including Java, since that
uses Carbon for drawing) can't be embedded in Cocoa views in Public Beta.
However, the platform-specific parts of Mozilla aren't all that big,
especially if you're talking about just the gecko engine and not the
terrible XUL UI. Embedding that in a Cocoa app wouldn't be a huge
undertaking, though you'd probably be better off doing in ObjC. (Especially
if you're doing it on Public Beta.)
--
Rick Roe
Webmeister & Icon Dude
http://www.icons.cx/ -
At 11:31 PM +0100 1/24/2001, Paul Libbrecht wrote:> That is a sad commitment: that means there will be no applets
> running for OmniWeb, or do I mistake ?? Or any other of these
> mixes... this is really, really sad.
>
> Is this war of incompatibility between Carbon and Cocoa going to
> last really long ?? This applet integration, was to me, a youth
> statement. If you say so for GM... I'll go to be a bit depressed...
That's right...applets will not work in OmniWeb at this time. We're
not at all satisfied with that state of things either, but embedding
a Carbon-based widget (e.g. a Java control) in a Cocoa application is
far too much of a technical hurdle to be solved in time for GM.
Improved compatibility between Carbon and Cocoa is clearly a
long-term goal, though, so we're hopeful that this'll be a high
priority post-GM. As far as I know -- and I don't really know the
technical issues involved except that they're quite nasty -- this
isn't something that Java can fix or work around on its own short of
rewriting the AWT to avoid Carbon.
-Eric
--
Eric Albert
<ealbert...> -
>> So basically I see what you're saying. Even if Java weren't involved, one
>> couldn't embed Mozilla into a Cocoa app just yet since it is a Carbon app.
>
> Yes and no. :)
>
> No, you probably can't drop the Mozilla engine into a Cocoa app without a
> bit of work. The part of the engine that has platform-specific variants
> comes Carbon and Java flavors; and Carbon views (including Java, since that
> uses Carbon for drawing) can't be embedded in Cocoa views in Public Beta.
Even with Java it's still quite a bit of work but It's also not too bad
either. Since I haven't done any classic Mac OS programing, I'd rather stay
away from Carbon.> However, the platform-specific parts of Mozilla aren't all that big,
> especially if you're talking about just the gecko engine and not the
> terrible XUL UI. Embedding that in a Cocoa app wouldn't be a huge
> undertaking, though you'd probably be better off doing in ObjC. (Especially
> if you're doing it on Public Beta.
Using Gecko is the only thing I'm interested in, XUL sucks! ;) Some of the
embedded Mozilla apps on Linux, such as Gaelon and Nautilus, are actually
very cool. It would be very nice to be able to do the same on OS X. But OjbC
is a bit beyond me at this point so I'll anxiously be awaiting the GM if it
every gets sent to ADC members. It'll also be interesting to see how the
Fizilla/Mach project is shaping up as well. That is the version of Mozilla
that will use a Carbon UI and BSD/Mach leveraged renderer.
Ryan-
+-----------------------------------------+
Ryan J. McDonough
http://www.randomthought.org
mailto:<ryan...>
+-----------------------------------------+ -
On Thursday, January 25, 2001, at 11:38 AM, Eric Albert wrote:> We're
> not at all satisfied with that state of things either, but embedding
> a Carbon-based widget (e.g. a Java control) in a Cocoa application is
> far too much of a technical hurdle to be solved in time for GM.
What about NSQuickDrawView?
andy
--
We fucked up. We fucked up big time.
-- Steve Jobs -
On Thursday, January 25, 2001, at 10:42 , Andreas Monitzer wrote:>> We're not at all satisfied with that state of things either, but
>> embedding
>> a Carbon-based widget (e.g. a Java control) in a Cocoa application
>> is far too much of a technical hurdle to be solved in time for GM.
>
> What about NSQuickDrawView?
Nope. That only creates a QuickDraw port not a WindowRef. Carbon
ControlHandles expect a WindowRef so they can do things like InvalRect.
Andrew
__________________________________________________________________
A n d r e w P l a t z e r
A p p l i c a t i o n F r a m e w o r k s
A p p l e
