Professional Web Applications Themes

Cursors again - Mac Programming

Hi, Now that I manage to re-display my cursor, I'm falling into another problem. I guess many of you have tried Photoshop. Remember the zoom tool ? When you press the alt key, it displays a '-' instead of a '+'. There also some subtle details. I'm trying to do the same thing. In order to reproduce this, I need to check keyboard and mouse moved events, BUT my view is NOT the first responder. Anyone got a clue ? Eric...

  1. #1

    Default Cursors again

    Hi,

    Now that I manage to re-display my cursor, I'm falling into another problem.
    I guess many of you have tried Photoshop. Remember the zoom tool ? When you
    press the alt key, it displays a '-' instead of a '+'. There also some
    subtle details. I'm trying to do the same thing.

    In order to reproduce this, I need to check keyboard and mouse moved events,
    BUT my view is NOT the first responder.

    Anyone got a clue ?

    Eric

    Eric Guest

  2. #2

    Default Re: Cursors again

    In article <BBD1C24A.14FBC%fr>,
    Eric VERGNAUD <fr> wrote:
     

    If your view is not the first responder, then you will have to check for
    changed modifiers somewhere else in the responder chain. Your NSWindow,
    and (I think) your NSWindow's delegates are both in the chain, so you
    can check for flagsChanged: there, and notify your view accordingly.
    Michael Guest

  3. #3

    Default Re: Cursors again

    dans l'article mail-48F165.08571108112003localhost, Michael Ash à
    com a écrit le 8/11/03 8:57:
     
    >
    > If your view is not the first responder, then you will have to check for
    > changed modifiers somewhere else in the responder chain. Your NSWindow,
    > and (I think) your NSWindow's delegates are both in the chain, so you
    > can check for flagsChanged: there, and notify your view accordingly.[/ref]

    Yes, that's what I've ended up doing, in MyWindow::sendEvent.


    Thanks.

    BTW, don't you think that this reveals weaknesses in the overall design of
    NSViews ? I find it very strange in 2003 to find a UI framework that makes
    it so difficult to do simple things.

    Eric

    Eric Guest

  4. #4

    Default Re: Cursors again

    In article <BBD2A95F.15017%fr>,
    Eric VERGNAUD <fr> wrote:
     

    I've never had any trouble doing this, probably because my views which
    need custom cursors have always been inside NSScrollViews (which have an
    easy method for setting cursors for their subviews) and are their
    windows' first responders, making it easy to catch flags changed events.

    It seems to me that your trouble at first came from the fact that you
    overrode a method in a custom NSWindow subclass and forgot to call
    super, which is a very bad thing to do. It's also very rare to need to
    subclass NSWindow to begin with, so are you sure that was necessary?
    Having to add some support code to check for flags changed because your
    view doesn't have the focus seems entirely reasonable to me.

    Given that my best metric for whether I'm choosing the right approach to
    solve a problem with Cocoa is, "If it takes more than ten minutes, I'm
    probably doing it wrong", I think that it's pretty good.
    Michael Guest

  5. #5

    Default Re: Cursors again

    dans l'article mail-A7499E.18010708112003localhost, Michael Ash à
    com a écrit le 8/11/03 18:01:
     
    >
    > I've never had any trouble doing this, probably because my views which
    > need custom cursors have always been inside NSScrollViews (which have an
    > easy method for setting cursors for their subviews) and are their
    > windows' first responders, making it easy to catch flags changed events.
    >
    > It seems to me that your trouble at first came from the fact that you
    > overrode a method in a custom NSWindow subclass and forgot to call
    > super, which is a very bad thing to do. It's also very rare to need to
    > subclass NSWindow to begin with, so are you sure that was necessary?
    > Having to add some support code to check for flags changed because your
    > view doesn't have the focus seems entirely reasonable to me.
    >
    > Given that my best metric for whether I'm choosing the right approach to
    > solve a problem with Cocoa is, "If it takes more than ten minutes, I'm
    > probably doing it wrong", I think that it's pretty good.[/ref]

    Well I was speaking more generally. I was very surprised to find there were
    no methods to hide subviews (I know it comes with Panther). It seems to me,
    although the technology itself is very mature, its design is not. I created
    a UI multiplatform framework almost 10 years ago, and I think one of the
    first thing I implemented was to allow that. The more I dig into Cocoa, the
    more I think it has the ambition to provide both a technlogy and a
    programming model. I don't think this is a good . There are many
    programming models out on the field, and depending on experience, skills and
    needs, programmers are allowed to choose which fits best. It seems to me
    Cocoa forces you into a programming model which is best suited for one task
    only. For example, it's much more difficult to write multiplatform
    applications using Cocoa than using Carbon. I'm currently porting a small
    framework to Cocoa, which requires some generic implementations which are
    also sometimes very difficult do work out. Much more than they are with
    Windows or Carbon.

    It seems to me that Cocoa engineers sometimes think they know application
    development better than application developers themselves. For example, what
    is this stupid design about mouseMoved events sent only to the
    firstResponder ?

    I hope in the future Cocoa engineers will focus on giving us both more and
    more high-level objects, and more and more low-level control on events and
    messages.

    Eric

    Eric Guest

  6. #6

    Default Re: Cursors again

    In article <BBD2F9E1.15032%fr>,
    Eric VERGNAUD <fr> wrote:
     
    > >
    > > I've never had any trouble doing this, probably because my views which
    > > need custom cursors have always been inside NSScrollViews (which have an
    > > easy method for setting cursors for their subviews) and are their
    > > windows' first responders, making it easy to catch flags changed events.
    > >
    > > It seems to me that your trouble at first came from the fact that you
    > > overrode a method in a custom NSWindow subclass and forgot to call
    > > super, which is a very bad thing to do. It's also very rare to need to
    > > subclass NSWindow to begin with, so are you sure that was necessary?
    > > Having to add some support code to check for flags changed because your
    > > view doesn't have the focus seems entirely reasonable to me.
    > >
    > > Given that my best metric for whether I'm choosing the right approach to
    > > solve a problem with Cocoa is, "If it takes more than ten minutes, I'm
    > > probably doing it wrong", I think that it's pretty good.[/ref]
    >
    > Well I was speaking more generally. I was very surprised to find there were
    > no methods to hide subviews (I know it comes with Panther).[/ref]

    Hiding views is actually kind of a discouraged thing. The introduction
    of a standard method to achieve it in Panther is, IMO, more a sign of
    resignation that people are going to do it so they might as well be
    helped to do it in the least wrong way.

    Mac OS has a fairly long history of making it really easy to do things
    the "right" way. Sometimes there's a legitimate need to take a divergent
    path, but it's much rarer than people seem to think.
     

    Ah, but now: Why?
     

    I disagree. I don't believe Cocoa forces anyone into a particular model.
    It very strongly encourages (a reasonably general) one, but force? No.
    And I really can't image what single task you think MVC is appropriate
    for.
     

    No. Unless you'd like to argue that since the gestalt of Cocoa is much
    more approachable than Carbon a programmer might be less inclined to use
    appropriate techniques and mechanisms for multi-platform work.

    G
    Gregory Guest

  7. #7

    Default Re: Cursors again

    In article <BBD2F9E1.15032%fr>,
    Eric VERGNAUD <fr> wrote:
     

    Before Pather, hide is [view retain]; [view removeFromSuperview];, and
    show is [superview addSubview:view]; [view release];. This has certain
    problems with autosizing and so on, but works pretty well. Hiding and
    showing is not a very useful thing, really. Most of the time, what you
    want is adding and removing, or a tab-view sort of situation, both of
    which already exist and work very well. What kinds of situations do you
    have where hide/show is really necessary?
     

    You are perfectly free to use any kind of programming model you want
    with Cocoa. If you don't like the responder chain, bypass it. If you
    don't like MVC, stuff everything into your NSView subclass. Of course,
    things become much harder if you do that, but that's perfectly normal;
    you're doing things where Cocoa won't help you out nearly as much.

    From what I see, Cocoa provides you with a lot of flexibility because of
    ObjC and OO. If something doesn't behave the way you need, you can
    subclass and change the behavior. And most of the time you don't even
    need to subclass, because every behavior that's commonly changed is
    exposed as a delegate method.
     

    Could this simply be because, first, Carbon and Win32 are a lot more
    similar in their approaches, and second, you are less familiar with
    Cocoa than you are with Carbon or Win32?

    Also, Cocoa is a Mac API, not a general GUI API. As such, it makes it
    easier to do things the Mac way than it does to do things in a non-Mac
    way. This is, I think, completely justifiable. You don't see people
    complaining that Carbon makes it hard to put a menu bar inside a window.
     

    All events are sent not only to the firstResponder, but to every object
    in the responder chain. If you need to get at mouse moved events and you
    aren't the first responder (which is quite rare, first, are you sure you
    need it?) then you can insert your code somewhere else in the responder
    chain.
     

    Do you have specifics on what you want? Apple is happy to listen to
    suggestions.
    Michael Guest

  8. #8

    Default Re: Cursors again

    Hey guys, I didn't mean to start a religious fight.

    I'm 95% satisfied with Cocoa, and my goal was only to make suggestions to
    improve it for me (an egoistic goal) and for other programmers.

    I've been a Mac supporter for 15 years, I love Apple, I hate Microsoft, I
    hate MFC. I hate PB, I love CW, I have'nt tried Xcode yet. However, many of
    my customers have Wintel boxes, so I also use VC++. Don't tell me you have
    only Mac customers. So like me, you need to write for various platforms,
    using various tools, and various appkits, which leads to this debate.

    First, I always find it very strange when people tell me I shouldn't need
    what I need. Gregory writes "Hiding views is actually kind of a discouraged
    thing ". Ah ? Why is that ? What's wrong about hiding objects ? A tab view
    is a very good example of a situation where you NEED to hide subviews. I
    KNOW you can do it another way (which is what I do, since I have no choice -
    at least on 10.2), but then you have to reference the hidden views
    somewhere, don't you ?

    Then he writes "The introduction of a standard method to achieve it in
    Panther is, IMO, more a sign of resignation that people are going to do it
    so they might as well be helped to do it in the least wrong way." Well
    that's exactly what I'm expecting from Cocoa engineers ! Humility. Reality
    is not what people think it is, or should be. It's different, versatile,
    because people out there are different. Some are beginners, some are
    experienced, some write their app from scratch, some are porting a Classic
    app written in C, some are porting a Windows app. No one is right, or all of
    them are. From a technology provider like Apple, I think they need to fit
    with the entire community, not just with programmers writing MacOSX only
    apps from scratch.

    As for mouse-moved events, that's exactly the subject where Cocoa forces you
    into a programming model. You MUST set the cursors for your view on
    resetCursorRects, but for some views (like a HTML page with links) that may
    be a lot of work, and may also be inappropriate if these cursors are
    dependant on keyboard state (like in my Photoshop example), or change all
    the time (like in a movie). If you were 'naturally' notified of mouseMoved
    events, then you would be able to set the cursor dynamically. There are many
    situations where a view is not the firstResponder, for example a HTML
    browser window with an address field. The address field is the
    firstResponder, but the cursor needs to change all the time when it's over
    the HTML display.

    Speaking of multi-platform development, let's give an example. MFC on
    Windows forces you into the MFC model, but you don't have to use MFC. You
    can very well use the WIN32 API. Where's the Cocoa equivalent ? Nowhere. You
    MUST use Objective-C, which AFAIK is not available on Windows, which is one
    of the reasons I say it's much less appropriate for multi-platform
    development.

    I KNOW I can override the default behaviour (which is what I do), but don't
    kill me if I say that how to do this is often poorly doented.

    Also I think it would be very convenient to have C accessors to the UI
    objects. I'm very confortable with OO, whether C++, Obj-C or Java, but how
    long did it take before I felt comfortable ? Years. I know many PROFESSIONAL
    programmers who are not comfortable with OO. They write apps in C on
    Windows. How can they port them to Cocoa ? Don't tell me they should use
    Carbon, bad answer, because many objects available in Cocoa are not
    available in Carbon (notably the auto spell-check text editor, and those of
    you who've tried making Textension work with HIViews know it's simply
    unusable). How many programmers out there feel confident enough to learn a
    new language ? That's one of the reasons why Microsoft .NET isn't the huge
    success Microsoft was hoping. I know many C++ programmers who don't WANT to
    learn a new language, whether C#, Java, or Obj-C. This is not an idea, it's
    a fact, and one of the reasons why Apple is forced to maintain Carbon. Don't
    you think Apple's limited resources would be used more efficiently on a
    single UI and Graphics layer, instead of maintaining Cocoa, Quartz, Carbon,
    Quickdraw and OpenGL ? If Cocoa was an acceptable replacement for Carbon,
    with a C API, C callbacks etc.., which is the programming model a great
    majority of developers are used to (even if they're using a C++ framework
    which encapsulates it (like MFC or PP)), no doubt they would move to Cocoa
    in a matter of 2-3 years, since there is so much benefit with the new UI
    objects.

    As a matter of fact, that's what I'm doing myself now, writing a C api for
    Cocoa, so I can use it in a multiplaform app (for which Java is not a
    choice).

    So what I'm hoping Cocoa engineers will do, besides providing us with more
    tremendous UI objects (and others) is:
    - make the 10.3 appkit available on 10.2 so we don't have to maintain
    specific code for that platform (it's an appkit isn't it, not an OS level
    component)
    - provide the equivalent of the Win32 'CaptureMouse' mechanism so we don't
    have to override every single Cocoa object to handle mouse events in a
    generic way
    - let events reach their targets whatever the context. We're grown up
    people.
    - provide a C API to Cocoa, so no one is forced into Obj-C

    Eric

    Eric Guest

  9. #9

    Default Re: Cursors again

    In article <BBD34504.15044%fr>,
    Eric VERGNAUD <fr> wrote:
     

    Two quick points here:
    1) The Cocoa equivalent is using Carbon, Quartz, and/or the BSD layer
    from Cocoa. All work fine.
    2) Your UI code wouldn't be cross-platform regardless of whether you
    wrote for Cocoa or Carbon. Both only work on Mac OS X. You can
    certainly write a UI frontend in Cocoa and a backend in C or C++.
    That's worked rather nicely for Safari, for example, with its use of
    KHTML. The Java implementation on Mac OS X is another example of this
    -- the Swing UI is Cocoa code, but the JVM is mostly cross-platform code.
     

    See
    <http://developer.apple.com/samplecode/Sample_Code/Human_Interface_Toolbo
    x/Mac_OS_X_HIToolbox/HITextViewShowcase.htm>.
     

    This is impossible, if only because AppKit's new features depend on new
    features elsewhere in the OS. Forget the name; like nearly all of the
    system frameworks, it is an OS-level component.
     

    This is also impossible. Objective-C provides a number of features that
    C and C++ don't (and can't), and which AppKit relies on.

    If you feel that AppKit makes certain things more difficult than they
    should be, file bug reports with Apple about them. Be sure to cite
    specific examples about what's difficult and how it could be improved.

    -Eric

    --
    Eric Albert edu
    http://rescomp.stanford.edu/~ejalbert/
    Eric Guest

  10. #10

    Default Re: Cursors again

    In article <BBD34504.15044%fr>,
    Eric VERGNAUD <fr> wrote:
     

    We aren't nearly at 'religious fight' levels... yet. :P If your goal is
    to make suggestions, and our goal is to make suggestions, no problem.
     

    Tab views are a good example of hiding objects, but of course NSTabView
    already exists.

    In the places where I've needed to "hide" views, it's been for optional
    configuration panels and things like that, where it actually makes a lot
    more sense to add and remove the subview than it does to just show and
    hide it, at least to me. The configuration panel is inside the window's
    contentView when it's visible, and it's completely removed when it's not
    needed. And of course somebody references it, the tool that needs
    configuration does. You have to reference a view to show or hide as
    well, if you want to re-show it, otherwise how will you find it?
     

    Apple has a long history of trying to make its users and programmers
    always do what it thinks is the Right Thing. Whether this is good or
    bad, it's something you have to live with.

    Also, a lot of the Mac's appeal comes from how most programs act in
    pretty much the same way, part of which comes from lots of doentation
    and encouragement, and part of which comes from their APIs making it
    easier to make programs that act like Mac programs than it is to make
    programs that act like Win32 or Qt programs. Some people think that it's
    better to have a few Windows programs ported over that look and feel
    exactly like Mac programs that it is to have a lot of Windows programs
    ported over that look and feel like Windows programs. (I'm not making
    any claims to the merits of these beliefs here, just stating them.)
     

    Your view is not necessarily the one that needs to be responsible for
    cursor tracking. This is something that could make sense in the
    controller, for example.
     

    I've never been in this situation before, so do NSView's trackingRect
    methods not work when the view is not the first responder?

    I'm not sure what you think of as 'natural', but subclassing NSWindow
    and having it send mouse moved events to whatever view you need is very
    quick and easy to do. For bonus points, have it automatically send them
    to the view under the mouse cursor. :)
     

    If you're doing cross-platform development, you should already have your
    interface well separated from the rest of your program, otherwise you'll
    run into trouble whenever you port to a platform whose GUI API is done
    in a different manner than where you're coming from. This is exactly
    what you're running into here.

    ObjC is available basically everywhere. Remember that Apple doesn't use
    some weird proprietary compiler, they use gcc, and gcc has supported
    ObjC for a long time. Object libraries are a different matter, of
    course, but there is GNUStep, and libFoundation if you just want the
    Foundation classes. ObjC may not fit well into the Windows world, I
    don't know, but it's at least available.
     

    If you say so. It takes some getting used to, and a good knowledge of
    how the system is put together, but once you have that I don't think
    it's too hard. And if you don't have that, of course things are
    difficult.
     

    They can't. Even if Cocoa somehow provided "C accessors", you couldn't
    write a Cocoa app. You could write an app that used Cocoa objects
    underneath, but it would be incredibly difficult to make a decent Cocoa
    application without the rich support provided by the Objective-C
    language.
     

    I think Carbon is a perfectly fine answer here. There are plenty of
    decent Carbon programs out there. And since you simply are never going
    to get the full benefit of Cocoa without actually learning an OO
    language, the choice isn't between Carbon and Cocoa at all, it's between
    Carbon and pseudo-Cocoa-in-C. I don't know what it would look like, but
    I bet Carbon would be better. Plus it's available today.
     

    Quite a few. I first learned Objective-C because I accepted a job
    writing an Objective-C program. I wasn't worried because I had heard it
    was easy to learn, and my employers weren't worried because I assured
    them it was easy to learn. And I was producing for them within a couple
    of days. Lots of people tell the same story.
     

    So let them stick with C. There's a perfectly good C API for Macs. I
    think you underestimate the difficulty of making Cocoa available to a
    non-OO language (and this counts C++, it's not dynamic enough to handle
    what's needed). Cocoa really relies on a lot of ObjC features, and it
    relies on the calling program taking advantage of them too. I don't see
    how it could be done well short of providing some macros for creating
    subclasses and telling everybody about objc_msgSend(), at which point
    you may as well get the syntactic sugar that a real ObjC compiler
    provides.
     

    Carbon and Cocoa are slowly growing together. Look at all of the NS/CF
    bridging, the ability to mix windows from the two APIs in the same
    program, mixing event handlers, etc. Carbon is, more or less, the C API
    to Cocoa. (Or Cocoa is the ObjC API to Carbon.) It may not let you
    access everything, but a hypothetical C API to Cocoa wouldn't let you
    access everything either.
     

    That would be nice, but it's not going to happen. Some of the new
    features do rely on additions to the OS, of course, and it *is* and
    OS-level component just as much as Carbon is. And of course, new
    programs which require 10.3 help drive upgrades of 10.3, which Apple
    likes. And they probably think that, old programs got by with the old
    APIs before, and they work on 10.3 anyway. New programs probably won't
    be concerned enough about the old OSes. If they are, they can just avoid
    the new APIs.
     

    "Every single Cocoa object"? Why is that necessary? Again, I haven't
    done it, but a simple subclass of NSWindow should do what you need.
     

    Events do reach their targets, you just have a different definition of
    'target' than Cocoa does. In which case you have to change the event
    dispatching mechanism, no surprise there.
     

    Again, that's not going to happen. Of course you aren't forced to use
    ObjC, you can use Java or Python or Ruby or Lisp or Perl or.... But you
    are forced to use a "real" (now *that* could start a religious war)
    object-oriented language, because the framework relies on it. Write a C
    API for Cocoa and you'll get Carbon, which we already have anyway.
    Michael Guest

  11. #11

    Default Re: Cursors again

    dans l'article mail-156FD3.12444509112003localhost, Michael Ash à
    com a écrit le 9/11/03 12:44:
     

    No.
     

    Which is what I've ended up doing, but I had to go through many
    difficulties, created bugs solved them etc... Before achieving this.
     

    Unfortunately, no. You won't get some the high level objects you get in
    Cocoa (scrollviews, auto spellcheck text editor), you won't get a
    thread-safe UI layer. One of the reasons I switched to Cocoa was NSTextView.
    I'm glad I did, but I really think the journey could have been nicer.

    Eric

    Eric Guest

  12. #12

    Default Re: Cursors again

    dans l'article stanford.edu, Eric Albert
    à edu a écrit le 9/11/03 10:08:
     

    No. You don't get all the Cocoa UI objects. You don't get a thread-safe UI
    layer.
     

    Come on Eric. Everybody knows that. I'm speaking of a cross-platform
    framework, not a cross-platform program. I have managed, in the end, to
    build (the part I need of) a cross-platform UI framework, but it required
    much more work to make the Cocoa version than the Carbon or the Win32
    version. Mostly because of its Obj-C only availability. It's definitely
    easier to port a program without changing programming language, don't you
    think ?

    Eric

    Eric Guest

  13. #13

    Default Re: Cursors again

    dans l'article stanford.edu, Eric Albert
    à edu a écrit le 9/11/03 10:08:
     

    Available only for 10.3 !

    Eric

    Eric Guest

  14. #14

    Default Re: Cursors again

    In article <BBD4321B.1506F%fr>,
    Eric VERGNAUD <fr> wrote:
     
    >
    > Unfortunately, no. You won't get some the high level objects you get in
    > Cocoa (scrollviews, auto spellcheck text editor), you won't get a
    > thread-safe UI layer. One of the reasons I switched to Cocoa was NSTextView.
    > I'm glad I did, but I really think the journey could have been nicer.[/ref]

    Cocoa is not particularly thread-safe either. It is somewhat thread-safe
    in certain areas, but I wouldn't go as far as to call it a "thread-safe
    UI layer". Although I seem to recall that many things in Carbon not only
    are not thread-safe, but aren't even safe to call at all from threads
    other than the main thread.

    Anyway, perhaps if you spent a whole lot of time wrapping Cocoa you
    could come up with a decent C API that was better than Carbon. But I bet
    if you spent that same amount of time working on Carbon itself, you
    could come up with the same thing. Automatic spell checking and things
    like that are not inherent to Cocoa, they just happen to exist there.
    There's no reason they can't be added to Carbon too. The way I see it,
    there are two types of Cocoa-only API features. One type is stuff that
    just happens to be there, and will probably get added to Carbon anyway.
    The other type is things that are possible because of the ObjC language,
    like Distributed Objects or NSArchiver, which you simply can't provide a
    C API for no matter what.
    Michael Guest

  15. #15

    Default Re: Cursors again

    In article <BBD435FE.1507A%fr>,
    Eric VERGNAUD <fr> wrote:
     
    >
    > Available only for 10.3 ![/ref]

    Yes. It's a new feature.

    -Eric

    --
    Eric Albert edu
    http://rescomp.stanford.edu/~ejalbert/
    Eric Guest

  16. #16

    Default Re: Cursors again

    In article <BBD43453.15071%fr>,
    Eric VERGNAUD <fr> wrote:
     
    >
    > No. You don't get all the Cocoa UI objects. You don't get a thread-safe UI
    > layer.[/ref]

    Of course you need to use Cocoa to use the Cocoa UI objects. That's
    expected. MFC doesn't have any of its own UI objects, which is why you
    can access them from Win32 -- they are Win32 objects. But try accessing
    an Avalon UI object in Longhorn from Win32 and you'll see that you can't.

    As for a thread-safe UI layer, well, there's little demand for one. Why
    do you *need* to update the UI from multiple threads? (I know it's
    convenient at times, but it's never necessary in my experience.) A UI
    framework that requires that updates occur on the main thread is simply
    easier to write and will be faster in the end. There's a reason why Sun
    switched Java from a multi-threaded UI model (AWT) to a single-threaded
    one (Swing).
     
    >
    > Come on Eric. Everybody knows that. I'm speaking of a cross-platform
    > framework, not a cross-platform program.[/ref]

    I didn't know that. The first message I read in this thread was the one
    I replied to.
     

    I'm sorry that you're using a cross-platform UI framework. :) Having
    spent a fair amount of my career working on them, I'd advise against
    using them in general. There's simply no way to construct a
    cross-platform UI framework that allows the Mac version to look and feel
    like a good Mac application and the Windows version to look and feel
    like a good Windows application.

    And as for Cocoa being harder to add in because it's Objective-C, well,
    there's really not much you can do about that except learn Obj-C (it's
    easy) and deal with it. Cocoa is what it is because it uses Obj-C. You
    can't separate them.

    -Eric

    --
    Eric Albert edu
    http://rescomp.stanford.edu/~ejalbert/
    Eric Guest

  17. #17

    Default Re: Cursors again

    dans l'article stanford.edu, Eric Albert
    à edu a écrit le 9/11/03 23:11:
     

    Well at least you need to update a progress bar ! It's safe to call
    [MyNSView needsRedraw], or [MyNSControl setIntValue] from any thread. Doing
    the equivalent in Carbon is more or less like a nightmare (whether using
    threads or MPTasks).
     

    Oh yes there is. I certainly disagree on this one ! I've done this during
    the last 15 years. There are so many common objects between Macs and Windows
    boxes that it's certainly worth the pain. Provided you build your UI on
    native objects (which is why I'm using Cocoa) and accept to specialize some
    parts of your UI (I'm thinking of special menus in the menu bar and stuff
    like that), you'll definitely have a good Mac application and a good Windows
    application, with at least 95% common code (in the app, not the framework).
     

    Well now we're back to the subject that started this thread !

    I don't agree on this. If it were true, it wouldn't be possible to use Cocoa
    in Java ! I've done a lot of Java work lately, and JNI stuff, and JNI
    definitely requires a C/C++ api. So while I doubt it will happen -unless
    someone at Apple suddenly discovers what a huge time-saver it would be for
    them to get rid of Carbon-, I don't believe it's not feasible (since I'm
    doing it myself).

    My feeling is that the people in charge of Cocoa WANT Objective-C to
    succeed. And I think this is wrong. First, as I said before, I don't think
    Objective-C will succeed, not because it's not a good language, but because
    there are already so many OO languages out there, and the benefits of Obj-C
    on C++ are not as obvious as Java's. But mostly, I think Apple shouldn't
    care about the language. That's a developer's choice. Remember the time when
    Apple provided us with C, pascal and assembly headers !

    Is Apple listening ? That's the question.

    Eric

    Eric Guest

  18. #18

    Default Re: Cursors again

    In article <BBD532CA.150BC%fr>,
    Eric VERGNAUD <fr> wrote:
     

    It's also fairly easy to perform an action in the main thread with
    Cocoa, although that's more of an ObjC thing and not so much a Cocoa
    thing. With a bit of clever design and olines, it can be as simple
    as [[myObject inMainThread] doStuff:blah withParameter:foo]. So oddly
    enough, a multithreadable UI is less necessary in Cocoa than Carbon.
     

    It is not correct to say that Cocoa depends on the exact way that ObjC
    does things. It is, however, correct to say that Cocoa depends on a
    weakly-typed object-oriented language with lots of introspection and
    delayed binding. This is something that is true of ObjC, Java,
    Smalltalk, and a whole bunch of other OO languages, but is not true of C
    (of course) or C++. Java and ObjC are quite similar in how they handle
    objects, which they should be since they both take their OO systems from
    Smalltalk.
     

    I don't get it. The fact is that the language Apple uses and the
    language you use don't have to match. Apple doesn't even have to approve
    of your language, or even know about it. You can program for Cocoa in
    probably a dozen different languages, of which only two are officially
    supported.

    Your complaint is not that Cocoa is bound to ObjC, it's that Cocoa is
    bound to OO. And while there isn't much in Cocoa that's particularly
    unique to ObjC, as you observed, it is *all* particularly unique to
    introspective late-bound object-oriented languages, and a comprehensive
    Cocoa interface for languages that don't support those features is
    simply never going to happen, both for technical and political reasons.
    Michael Guest

  19. #19

    Default Re: Cursors again

    dans l'article mail-D7A968.17584210112003localhost, Michael Ash à
    com a écrit le 10/11/03 17:58:
     

    I'm not complaining. Just trying to sit back and give it some thoughts.

    Eric

    Eric Guest

  20. #20

    Default Re: Cursors again

    In article <BBD5A5BF.15118%fr>,
    Eric VERGNAUD <fr> wrote:
     
    >
    > I'm not complaining. Just trying to sit back and give it some thoughts.[/ref]

    Well, call it what you will. Complaining, suggesting, it's not that
    important what it is. Your *suggestion*, then, was not to provide Cocoa
    for "some other language" (which can be and has been done), but to
    provide Cocoa for a specific other language that lacks the features
    required. The fact that Cocoa is available in other languages that do
    support the required features has no bearing on the possibility of
    making Cocoa available in C.
    Michael Guest

Page 1 of 2 12 LastLast

Similar Threads

  1. Cursors
    By flashster in forum Macromedia Director Lingo
    Replies: 8
    Last Post: December 12th, 01:47 PM
  2. posible BUG in CURSORS...
    By Gabriel Sebastián Rivera in forum Macromedia Director Lingo
    Replies: 1
    Last Post: December 2nd, 02:58 PM
  3. cursors problem
    By sylmy webforumsuser@macromedia.com in forum Macromedia Director Basics
    Replies: 1
    Last Post: October 22nd, 07:05 PM
  4. Are Cursors in Triggers really bad?
    By George Wynne in forum Microsoft SQL / MS SQL Server
    Replies: 6
    Last Post: July 1st, 03:50 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139