Re: Animated toolbar
Re: Animated toolbar
- Subject: Re: Animated toolbar
- From: Christian Graus <email@hidden>
- Date: Sat, 7 Feb 2009 14:25:21 +1100
On Sat, Feb 7, 2009 at 1:56 PM, Kyle Sluder <email@hidden> wrote:
> On Fri, Feb 6, 2009 at 9:32 PM, Christian Graus
> <email@hidden> wrote:
> > We prefer users to use our app full screen. we're copying our Windows
> > program, so we really don't have a lot of room to rethink this stuff, and
> > what we've done so far, was a success in the windows world. I am trying
> to
> > make sure we move from windows centric UI to Mac centric UI where
> > appropriate, but in this case, I am pretty sure my boss isn't going to
> > budge.
>
> What works in the Windows world very, very often does not translate
> well to the Mac. When you say you "prefer users to use our app full
> screen," does this correlate to a maximized window on Windows or to a
> true full-screen app? If the former, your users will not use the app
> as you intended. If the latter, then it has a far greater chance at
> working. On Windows, maximized is almost the default window size. On
> the Mac, there is no such thing as "Maximizing"; there's Zooming,
> which toggles between the last size a user made for the window and the
> app's preferred size for that window.
>
It's a true full screen app, most of the time. Obviously, you are right,
this is an issue that we're going to face, but, again, I've voiced my
concerns, and I am not getting the final say on this.
>
> > Well, perhaps. But, what I understand is that I have a boss who expects
> me
> > to write Objective C code as fast as I write C# code, and yes, at this
> > point, I really don't understand the best way to create what I need to,
> > that's why I was asking. I also find google to be the best way of
> finding
> > documentation, although I have many books, google usually works better.
>
> You have a categorically unreasonable boss. I take it he was never a
> developer himself, or if he was, he never worked on any platform other
> than Windows?
>
He has never written a line of code in his life. Can I send him this email
? :P
>
> > I've been in Interface Builder, and I have been unable to even work out
> how
> > to add a child window that I can animate in the manner I am hoping for,
> and
> > I am certainly concerned that if I start off with the wrong thing, I will
> do
> > work that I end up having to scrap. I have 24 hours in which to add this
> > toolbar, and get some other work done, too. I've purchased a number of
> > books, and I've been looking at them, my core assumption here is that if
> I
> > had a reasonable amount of time to immerse myself in the framework, I
> could
> > work all this out. As it stands, I have time pressure, little
> experience,
> > and I am looking for shortcuts that I have no doubt I will go back and
> > improve upon when I have the time.
>
> 24 hours is not nearly enough time to understand all the concepts that
> are necessary in pulling this feature together. Barring the thought
> of even approaching the Dock's appearance, mimicing its functionality
> alone will require you to understand a lot of things: the view
> hierarchy (which is radically different from the Windows model of
> everything-is-a-window), NIB loading/MVC (so you can actually connect
> your code to the interface), Core Animation (a Leopard-only technology
> that is designed to do things like what you're trying to accomplish),
> Quartz (if you have to target releases before Leopard or need to do
> reasonably involved custom drawing), and more...
>
I've actually spent the last day changing our existing code to use
IKImageView, and have the zoom working on that, there are aspects of this
that I understand, this toolbar is not my first Objective C task, or Cocoa
task. I also have a strong C++ background, so I'm not totally starting from
zero here. But yes, I agree that there's a lot I am trying to grasp in a
short space of time, and if I had any choice, I'd be asking far more basic
questions as I build the skillset to truly be able to design and understand
the code I am trying to create on short notice. As I said, once I get past
this deadline, I will certainly be digging deeper, and no doubt going back
to improve on whatever I crank out in the next day or so.
>
> If you can afford to target Leopard only, you might be able to get
> away with this: put a bunch of NSImageViews in an otherwise-empty
> NSView, subclass NSWindowController, create an instance of it to
> manage your window, add an outlet for the containing NSView, set the
> class of File's Owner in your window's NIB to your custom subclass,
> wire up the outlet you created, and trap incoming mouse events to
> deduce where they are in respect to your container view and resize its
> child views accordingly.
>
> This is not easy, and probably not complete since I'm coming up with
> it off the top of my head.
>
OK - I see what you're suggesting. I will think about this some more when I
come back to this tonight, it at least gives me a starting point. Like I
said, I was hoping for some sort of sample ( our code in C# is actually
based on a Windows WPF sample that does this, so I guess I can dig into that
for the math to work out the rates of resizing, etc ), but only because of
time constraints.
>
> > Yes, that's true - I know it to be true. Sadly, I am not in a position
> to
> > do anything about the time pressures on me, in fact, I had allocated more
> > time to work on this, this week, and instead was pulled into work on our
> > Windows version which has left me even more time poor. I guess it's hard
> > for you to discern if I am in need of help b/c of an unrealistic
> deadline,
> > or if I'm asking such broad questions because I can't be bothered trying
> to
> > work stuff out for myself.
>
> You are correct; that's a distinction impossible to discern from your
> initial post. To be frank, we've had an increasing number of Windows
> developers come here and ask for step-by-step instructions on
> re-implementing half the operating system.
>
ROTFL !!! I bet you do. I've been reading the list for some time, and have
asked a couple of things here and there, but, sadly, all the time I
allocated for learning Cocoa was taken from me with Windows tasks. I guess
it's a sign that Mac market share is growing. I'm certainly all Mac now,
which was pretty much my response to both Vista, and knowing I needed to
start learning to code for Mac.
>
> > And I was not looking for step by step instructions, I was really hoping
> > that somewhere there was a sample I could read to see how to get the
> > animation right, and perhaps some instructions on how to add an animated
> > child window ( both of which seem to me the sort of thing I'd expect to
> find
> > articles on, online ). Perhaps I've been spoiled by sites like
> > CodeProject.com, I've not found anything analogous in the Mac world, so
> far.
>
> Nothing of the sort exists in the Mac world. Personally, I think
> sites like CodeProject contribute heavily to the sorry state of modern
> software development. They encourage copy-paste coding and convince
> everybody who can breathe without assistance that they can make a
> living as a contract coder, leading to nightmarish maintenance
> scenarios for the competent developers left holding the bag.
>
Yeah, I would tend to agree with this. I am the top poster on Code Project
( I also worked for them for a while ), but my feeling is that it's become a
place for people who have no idea and who don't want to learn, to get others
to do their work for them. That's definitely not my attitude ( I really
want to learn Cocoa, and I don't expect anyone to do my job for me ), but at
this point, I am stuck with an untenable deadline, and I was looking for a
short cut.
>
> I also think that part of the reason you don't see examples of the
> sort you were expecting is that within the comparatively miniscule
> Macintosh development community, there are a lot of old-hat
> developers. The Apple sample code is pretty much as good as it gets,
> along with the examples that others have so graciously provided. But
> they all seem to focus on a specific feature or set of features, not
> in a concrete goal -- they're meant to explain concepts and provide
> enough background that the reader can go off and understand the
> reference material available and gain an understanding of the
> technology as a whole. You won't find people writing articles on "How
> to Make your Own Dock Clone" with the intent of providing a recipe to
> others with that aim.
>
Well, fair enough. As you're no doubt aware, Code Project articles pretty
much aim to provide people with reusable components. I don't see anything
wrong with that - I've written quite a few articles myself, including a
series on image processing that has kept me in paid work for years. But,
the paradigm is changing, and, there's no reason to expect the Windows and
Mac worlds to work the same way, because the communities are bound to
differ, for the reasons you stated, as well as the flood of under paid,
under skilled contractors taking over the windows forums.
I appreciate the discussion, more than anything, you've got me wondering if
I need to dig my heels in on a different UI for our tools on the Mac. I'm
not sure how we'd go on a Mac taking over the whole screen and suppressing
the Dock, and that seems to me what we'd need to do, so it doesn't come up
when our toolbar does. And, one core thing I am willing to fight for, is a
willingness to change our UI paradigms to make sure they are Mac friendly.
We're not going to do a Lotus Notes and create a UI that is the same
everywhere, and sucks everywhere.
Thanks again
Christian
>
> --Kyle Sluder
>
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden