xcode app to display a webpage
nowa...@gmail.com
friend got it autoloading in there just fine but then lost it trying to
do something else.
one thing i would like to add later is some buttons to various sites,
or a bookmark menu item, or something unobtrusive of the like that can
hold a decent amount of links.
ive tried a couple of tutorials but they pretty much got me nothing but
tons of errors and didnt describe where to even put anything and im
prett ysure this isnt THAT complex afterall, its just putting the
webview thing in the interface then running some code somewhere to
autoload a page when the window is open.
jollyprez
http://developer.apple.com/opensource/internet/webkit.html
Hope that helps.
Jolly
David Phillip Oster
nowa...@gmail.com wrote:
> ive got a webpage i want to display in its own app (dont ask..). my
> friend got it autoloading in there just fine but then lost it trying to
> do something else.
>
I tested the following recipe:
To write a Cocoa program to display a web page (in this example, it is
http://www.apple.com, but it could be anything.)
1.) In XCode: Make a new Cocoa Project
2.) In Finder: Open the folder /System/Library/Frameworks and drag the
WebKit.framework into the Frameworks folder icon of your Xcode project
window.
3.) In XCode: Double-click on MainMenu.nib to launch it in Interface
builder.
4.) in Interface Builder: In the Classes tab of MainMenu.nib right click
on NSObject. Subclass it to make the class AppDelegate
5.) Right Click on AppDelegate to add an outlet named: webView of type
WebView to AppDelegate.
6.) Right Click on AppDelegate to instantiate the class.
7.) Right Click on AppDelegate to create files.
8.) in Interface Builder: In the Instances tab of MainMenu.nib,
* Double click on "Window" to open it.
* Drag a WebView object from "Graphic Views" tab of the Cocoa
Palettes window to "Window". resize it to fill the window. In
Inspector's Size tab, set the size of the Web view to the full size of
the window, and turn on the inner springs both horizontal and vertical.
9.) next, Control-Drag from AppDelegate to the webView, and connect it
as the webView outlet of the AppDelegate.
10.) in Interface Builder: In the Instances tab of MainMenu.nib,
Control-Drag from File's Owner to AppDelegate, to set it as the delegate.
With practice, you'll be able to do the above 10 steps faster than you
can read them.
Now we're ready to write some code. Add one line to AppDelegate.h to
make it look like this:
/* AppDelegate */
#import <Cocoa/Cocoa.h>
@class WebView; // <-- add this line.
@interface AppDelegate : NSObject {
IBOutlet WebView *webView_;
}
@end
and make AppDelegate.m look like this:
#import "AppDelegate.h"
#import <WebKit/WebView.h>
#import <WebKit/WebFrame.h>
@implementation AppDelegate
- (void)awakeFromNib {
WebFrame *mainFrame = [webView_ mainFrame];
NSURL *url = [NSURL URLWithString:@"http://www.apple.com"];
NSURLRequest *request = [NSURLRequest requestWithURL:url];
[mainFrame loadRequest:request];
}
@end
That's all. You are done. You can run it, and it will fetch the web page
from the web and display it in the view.
How did I learn to do this? I read the comments in WebKit/WebView.h and
the rest was obvious, if you've worked through the book: "Cooca
Programming for Mac OS X" by Aaron Hillegas (Second Edition.)
> one thing i would like to add later is some buttons to various sites,
> or a bookmark menu item, or something unobtrusive of the like that can
> hold a decent amount of links.
Once you've got the page, if you can't edit the original HTML on the
original website, is to implement WebFrameLoadDelegate, and when the
page is loaded use some of the DOMElement calls to edit the DOM
(Document Object Model) to add some buttons that will call back into
your Cocoa.
>
> ive tried a couple of tutorials but they pretty much got me nothing but
> tons of errors and didnt describe where to even put anything and im
> prett ysure this isnt THAT complex afterall, its just putting the
> webview thing in the interface then running some code somewhere to
> autoload a page when the window is open.
As you see. Just a few lines of code.
Santa Claus
launching a class when the main program launches? that's the only part i haven't
worked out, launching something via the nib files and launching something upon
program launch.
point me to however many instructions from Apple but they read like a HP programming
manual or the complete ten thousand page tax code (is it only ten thousand pages long?).
that's why i don't use nib files honestly.
In article <oster-9D4D99....@newsclstr02.news.prodigy.com>,
Michael Ash
> These instructions are great! would you mind sending instructions on simply
> launching a class when the main program launches? that's the only part i haven't
> worked out, launching something via the nib files and launching something upon
> program launch.
>
> point me to however many instructions from Apple but they read like a HP programming
> manual or the complete ten thousand page tax code (is it only ten thousand pages long?).
Then it's probably time to get a book. There are a lot of good books out
there:
http://www.cocoadev.com/index.pl?CocoaBooks
You've been posting in here for well over a year and your understanding is
still extremely weak. Your question isn't even sensical ("launch a class"
is meaningless) and even when interpreted to something that does make
sense (such as "execute some code"), it's something so basic that it's
hard to see how you've gone this far without learning it. This is probably
an indication that you're doing something very wrong.
> that's why i don't use nib files honestly.
This is very bad. Cocoa is built around nibs in much the same way that
UNIX is built around files or lisp is built around conses. You may be able
to avoid using them, but you're fighting the system at a deep level and
you will suffer greatly for it. Making such a gigantic design mistake
simply because you don't know how to run some code at app startup is a
decision I am not really able to understand.
--
Michael Ash
Rogue Amoeba Software
Santa Claus
Michael Ash <mi...@mikeash.com> wrote:
> Santa Claus <sa...@northpole.com> wrote:
> > These instructions are great! would you mind sending instructions on simply
> > launching a class when the main program launches? that's the only part i haven't
> > worked out, launching something via the nib files and launching something upon
> > program launch.
> >
> > point me to however many instructions from Apple but they read like a HP programming
> > manual or the complete ten thousand page tax code (is it only ten thousand pages long?).
>
> Then it's probably time to get a book. There are a lot of good books out
> there:
>
> http://www.cocoadev.com/index.pl?CocoaBooks
and what happens if i already HAVE the books and they still make no sense?
they are good for taking up room on the shelf but...
>
> You've been posting in here for well over a year and your understanding is
> still extremely weak. Your question isn't even sensical ("launch a class"
> is meaningless)
ok, let me make myself a bit more clear... i know i'm not that good at expressing myself
to all of you so let me explain what i'd like to know...
you run textedit or any basic app that you made using nibs and you can get something working
go to the file menu and select new and you got a new window and the initialization routine for
that window takes over and you start seeing things happen (or not).
now you want to run this game called halo or age of mythology. none of them require the user
to select new from the file menu to start their games.
i can handle my way around the nib files myself if i simply knew how the app starts up.
NONE of the books i've seen even remotely describe the startup process for an app (what
is loaded, when it's loaded, where your app startup routine goes)
do i simply write (take an app called "santa.app" as an example) a class called santa and
have that's initialization routine initialize my stuff, compile it ant it works?
i actually tried that aspect and it was a no-go
you all keep pointing me to a comprehensive list of books which i have no interest in buying
the whole set (nor do i have the money to buy the set). give me a book name and chapter my
questions would be answered by and i'll be happy to read it and if i don't have it, i'll buy it.
> > that's why i don't use nib files honestly.
>
> This is very bad. Cocoa is built around nibs in much the same way that
> UNIX is built around files or lisp is built around conses. You may be able
> to avoid using them, but you're fighting the system at a deep level and
> you will suffer greatly for it. Making such a gigantic design mistake
i see, having real-time menus that change with the contents of folders or other stuff
is against the "natural order" right? real-time button windows that have their pictures
change depending on data received is also against the natural order? Writing windows and
other stuff that LOOKS like it came from a nib file is easy to program NOW (i must admit,
earlier i had one heck of a time getting everything to work). since i mainly write an
expander for somebody else's work instead of an app, i didn't think nibs would work so i
didn't even try it. now that i need to write my own app, i would like to at least TRY the
suggested way of doing things. pardon me for asking and taking up so much of your time.
i was under the mistaken impression that this was the newsgroup comp.sys.mac.programmer.help
where you could ask questions without being blasted by folks calling you an idiot.
Robert Dell
Michael Ash
> In article <11671077...@nfs-db1.segnet.com>,
> Michael Ash <mi...@mikeash.com> wrote:
>
>> Santa Claus <sa...@northpole.com> wrote:
>> > These instructions are great! would you mind sending instructions on simply
>> > launching a class when the main program launches? that's the only part i haven't
>> > worked out, launching something via the nib files and launching something upon
>> > program launch.
>> >
>> > point me to however many instructions from Apple but they read like a HP programming
>> > manual or the complete ten thousand page tax code (is it only ten thousand pages long?).
>>
>> Then it's probably time to get a book. There are a lot of good books out
>> there:
>>
>> http://www.cocoadev.com/index.pl?CocoaBooks
>
> and what happens if i already HAVE the books and they still make no sense?
> they are good for taking up room on the shelf but...
Then you need to start thinking about what you're doing wrong. Maybe it's
a simple matter of devoting more effort, or maybe you need to look more at
examples and less at texts, or maybe you need to invest in an actual
real-world class. I don't know what your learning style is so I don't know
what you need to do, but clearly whatever it is you're doing now just
isn't working.
>> You've been posting in here for well over a year and your understanding is
>> still extremely weak. Your question isn't even sensical ("launch a class"
>> is meaningless)
>
> ok, let me make myself a bit more clear... i know i'm not that good at expressing myself
> to all of you so let me explain what i'd like to know...
> you run textedit or any basic app that you made using nibs and you can get something working
> go to the file menu and select new and you got a new window and the initialization routine for
> that window takes over and you start seeing things happen (or not).
>
> now you want to run this game called halo or age of mythology. none of them require the user
> to select new from the file menu to start their games.
>
> i can handle my way around the nib files myself if i simply knew how the app starts up.
> NONE of the books i've seen even remotely describe the startup process for an app (what
> is loaded, when it's loaded, where your app startup routine goes)
>
> do i simply write (take an app called "santa.app" as an example) a class called santa and
> have that's initialization routine initialize my stuff, compile it ant it works?
>
> i actually tried that aspect and it was a no-go
This is what I had guessed at what your question meant, as I indicated in
the parts of my message which you snipped. My point with the part you
quoted was simply that you're so confused your terminology makes no sense.
I realize that in some respects it's just semantics, but in a very real
sense if you make statements like "launch a class" then that means you
have, at best, an extremely shallow understanding of the fundamentals.
> you all keep pointing me to a comprehensive list of books which i have
> no interest in buying
> the whole set (nor do i have the money to buy the set). give me a book
> name and chapter my
> questions would be answered by and i'll be happy to read it and if i
> don't have it, i'll buy it.
I'm sure that *any* book which describes how to build a Cocoa application
will tell you how to execute code on application startup.
>> > that's why i don't use nib files honestly.
>>
>> This is very bad. Cocoa is built around nibs in much the same way that
>> UNIX is built around files or lisp is built around conses. You may be able
>> to avoid using them, but you're fighting the system at a deep level and
>> you will suffer greatly for it. Making such a gigantic design mistake
>
> i see, having real-time menus that change with the contents of folders
> or other stuff
> is against the "natural order" right? real-time button windows that
> have their pictures
> change depending on data received is also against the natural order?
No. When did I say that this was the case? It is possible to write code
that both uses nibs and dynamically changing content. In fact, it is
easier to write this code than it is to write the equivalent code without
nibs.
You are imagining constraints ("no dynamic content with nibs") which don't
actually exist, simply because you haven't been able to figure out how.
> Writing windows and
> other stuff that LOOKS like it came from a nib file is easy to program
>NOW (i must admit,
> earlier i had one heck of a time getting everything to work). since i
> mainly write an
> expander for somebody else's work instead of an app, i didn't think
> nibs would work so i
> didn't even try it.
It really depends on what the stuff you're working with does. If it wants
to manually position every single button and field, yeah, nibs are pretty
much pointless. But if you have some freedom in building your own UI then
nibs are the way to go.
> now that i need to write my own app, i would like
> to at least TRY the
> suggested way of doing things. pardon me for asking and taking up so
> much of your time.
The suggested way of doing things is to use nibs. The suggested way of
doing things is also to learn the basics on your own and use newsgroups
and other resources as a place where you can ask hard questions when you
need expert help. Discovering applicationDidFinishLaunching: is not
something that requires expert help.
> i was under the mistaken impression that this was the newsgroup
> comp.sys.mac.programmer.help
> where you could ask questions without being blasted by folks calling
> you an idiot.
The first occurrence of the word "idiot" in this thread is right there in
your message, as far as I'm aware. If you don't like the tone of my post
then that's fine, some people just can't handle having their deficiencies
pointed out, but don't just make up things to make me look bad.
David Phillip Oster
Santa Claus <sa...@northpole.com> wrote:
> do i simply write (take an app called "santa.app" as an example) a class
> called santa and
> have that's initialization routine initialize my stuff, compile it ant it
> works?
1.) Create a New Cocoa Application Project in Xcode.
2.) Create a new class file. Name it MyApp.m Edit the top line of the .h
file so that it reads:
@interface MyApp : NSApplication
{
}
....
that is, inherit from NSApplication instead of NSObject
3.) This is the tricky part: Open the project's Info.plist and change the
value of the NSPrincipalClass <key> from NSApplication to MyApp
4.) In MyApp.m, add:
@implementation MyApp
- (void)awakeFromNib {
NSLog(@"Hello World");
}
@end
Run it and verify that you get control, that HelloWorld shows up in the
Xcode "Run Log" window (if running), or the Xcode "Console Log" window,
(id debugging). Now you can do what initialization you like.
------------------------------
More traditional would be to create a subclass of NSObject, open
MainMenu.nib, read the class .h file into the classes tab, instantiate
your class, and in the instances tab <Control>-Drag from File'sOwner to
your instance, and connect it as the app's delegate.
Once again, put your code in your class's
- (void)awakeFromNib {
}
------------------------------
Look at other people's sample code. Think about why you are finding the
books impenetrable.
Santa Claus
David Phillip Oster <os...@ieee.org> wrote:
thank you, this is the precise information i needed that i couldn't figure out
from anywhere.
now to get a microphone for speech input that works under the
high magnetic fields of the power lines nearby... (yeah, i know... not part
of this discussion)...
Santa Claus
Michael Ash <mi...@mikeash.com> wrote:
> It really depends on what the stuff you're working with does. If it wants
> to manually position every single button and field, yeah, nibs are pretty
> much pointless. But if you have some freedom in building your own UI then
> nibs are the way to go.
i agree, that's one of the main reasons i don't want to change one of my
windows with 14 buttons, dividing each one into 4 buttons (a daunting task)...
Gregory Weston
> In article <11671077...@nfs-db1.segnet.com>,
> Michael Ash <mi...@mikeash.com> wrote:
>
> > Santa Claus <sa...@northpole.com> wrote:
> > > These instructions are great! would you mind sending instructions on
> > > simply
> > > launching a class when the main program launches? that's the only part i
> > > haven't
> > > worked out, launching something via the nib files and launching something
> > > upon
> > > program launch.
> > >
> > > point me to however many instructions from Apple but they read like a HP
> > > programming
> > > manual or the complete ten thousand page tax code (is it only ten
> > > thousand pages long?).
> >
> > Then it's probably time to get a book. There are a lot of good books out
> > there:
> >
> > http://www.cocoadev.com/index.pl?CocoaBooks
>
> and what happens if i already HAVE the books and they still make no sense?
> they are good for taking up room on the shelf but...
Either you've got the wrong books or you need to take a couple of steps
back in your training. The Hillegass books, for example, are quite
approachable and make very few assumptions.
> i can handle my way around the nib files myself if i simply knew how the app
> starts up.
> NONE of the books i've seen even remotely describe the startup process for an
> app (what
> is loaded, when it's loaded, where your app startup routine goes)
>
> do i simply write (take an app called "santa.app" as an example) a class
> called santa and
> have that's initialization routine initialize my stuff, compile it ant it
> works?
Yep. Depending, largely, on what you think the class's "initialization
routine" is.
> > > that's why i don't use nib files honestly.
If you don't understand a tool, not using it is one response. Another is
to learn how to use it.
> > This is very bad. Cocoa is built around nibs in much the same way that
> > UNIX is built around files or lisp is built around conses. You may be able
> > to avoid using them, but you're fighting the system at a deep level and
> > you will suffer greatly for it. Making such a gigantic design mistake
>
> i see, having real-time menus that change with the contents of folders or
> other stuff is against the "natural order" right?
Depending on what you mean by "change" having menus that do it can be
good or bad, but it has nothing to do with "the natural order" and much
to do with effective and efficient user interaction. A menu ITEM whose
applicability and behavior may change contextually should change to
reflect that. That's why items dim when they are irrelevant and why in
decent apps the Undo command actually describes the activity it will
undo. Having MENUS that change, by the insertion or removal of items at
times that have no clear relationship to user activity is bad because it
destroys muscle memory. But whether you choose to do either of those has
not a thing to do with whether you use NIBs. How you create your objects
at launch has no bearing on what you do with them later on.
> real-time button windows that have their pictures
> change depending on data received is also against the natural order?
Nope. Not in the slightest.
> Writing
> windows and
> other stuff that LOOKS like it came from a nib file is easy to program NOW (i
> must admit,
> earlier i had one heck of a time getting everything to work).
I think that's a major point in this discussion. The time you spent
learning how to avoid using NIB files would probably have been much
better spent learning how to use them.
> i was under the mistaken impression that this was the newsgroup
> comp.sys.mac.programmer.help
> where you could ask questions without being blasted by folks calling you an
> idiot.
It's a microcosm. You'll find people across the whole continuum of
politeness and patience. And you often get what you give. One of the
things you'll find, though, is that when you ask for help in a help
group and then reject the responses you get, people tend to get less
friendly. The tone of your post is hostile. Don't be surprised if some
people react with hostility. (And looking at Google, not only has noone
called you an idiot...noone's been particularly rude or harsh so far.)
--
The best intentions in the world don't make a flawed argument magically valid.