From cnguyen at stata.com Thu May 3 12:08:30 2007 From: cnguyen at stata.com (Chinh Nguyen) Date: Thu, 3 May 2007 11:08:30 -0500 Subject: [WASTE-list] WEChangeCase broken? In-Reply-To: References: Message-ID: <6988C199-B69D-4B25-9785-DE097F6F5A36@stata.com> I just noticed WEChangeCase() in WASTE 3.0.1 is broken or is it just me? -Chinh Nguyen cnguyen at stata.com From marco.piovanelli at pobox.com Thu May 3 12:39:01 2007 From: marco.piovanelli at pobox.com (Marco Piovanelli) Date: Thu, 3 May 2007 18:39:01 +0200 Subject: [WASTE-list] WEChangeCase broken? In-Reply-To: <6988C199-B69D-4B25-9785-DE097F6F5A36@stata.com> References: <6988C199-B69D-4B25-9785-DE097F6F5A36@stata.com> Message-ID: <20070503163901.1672567203@relay.pair.com> On Thu, 3 May 2007 11:08:30 -0500, Chinh Nguyen (cnguyen at stata.com) wrote: >I just noticed WEChangeCase() in WASTE 3.0.1 is broken or is it just me? You're right. That API is currently non-functional in WASTE 3.0.1. I can think of a couple of partial workarounds for the lack of WEChangeCase(), but one only works on monostyled text runs, and the other doesn't work for characters like the German esszett (?), which changes to two characters (SS) when uppercased. -- marco -- It's not the data universe only, it's human conversation. They want to turn it into a one-way flow that they have entirely monetized. I look at the collective human mind as a kind of ecosystem. They want to clear cut it. They want to go into the rainforest of human thought and mow the thing down. From marco.piovanelli at pobox.com Thu May 10 11:15:43 2007 From: marco.piovanelli at pobox.com (Marco Piovanelli) Date: Thu, 10 May 2007 17:15:43 +0200 Subject: [WASTE-list] [ANN] WASTE 3.0.2 now available Message-ID: <20070510151543.192940897@relay.pair.com> Hi all, WASTE 3.0.2 is now available for download at: This release fixes a number of bugs that were discovered in the last few months, and adds a number of features. NEW FEATURES: ============= * Added support for the Pasteboard Manager. WASTE will now use Pasteboard Manager APIs internally for most cut and paste operations, instead of the old Carbon Scrap Manager APIs. Also, the framework now exports the following APIs for pasteboard support: WECopyToPasteboard WEPasteFromPasteboard WECanPasteFromPasteboard * The framework now exports the following new APIs for spell checking and dictionary lookup purposes. The prototypes aren't frozen yet, so use with care: WEGuessSpelling WEIgnoreSpelling WELearnSpelling WELookUpInDictionary * Added the following HI commands to the list of commands handled by WASTE: kHICommandFindNext kHICommandUseSelectionForFind kHICommandJumpToSelection kHICommandLookUpInDictionary BUG FIXES: ========== * WEKey() no longers throws a paramErr exception when a Unicode keyboard is selected. * The weTagDirection paragraph attribute is now functional. When no dominant line direction is explicitly set, left-to-right is assumed. * In some rare cases, WEGetDestRect() could let a C++ exception go uncaught, potentially causing the abrupt termination of the client application. * WEGetObjectAtOffset) was incorrectly returning an object reference for offsets equal to, or greater than, the actual text length, if the document contained an embedded object at the very end of the document. Thanks to Alfred Van Hoek. * In the same scenario as the above (embedded object at the very end of the document), WEFindNextObject() was incorrectly returning the same object reference over and over, potentially causing the client to enter an infinite loop. Thanks to Alfred Van Hoek. * When a C++ exception is thrown (and caught) within the WASTE framework, WASTE will print a detailed description to stdout, but only if the environment variable "WASTE_DEBUG" is defined. Previously, there was no way to turn off these debugging messages. On Tiger, exception descriptions include strings obtained from GetMacOSStatusErrorString() and GetMacOSStatusCommentString(). * Silenced a harmless exception in WE3_ATSULayout::MoveCursor() noted when using arrow keys in empty documents. Thanks to Chinh Nguyen. * When saving a document to an RTFD package, WESave() would fail unless a "TXT.rtf" file was already present in the bundle. * The weTagAddFontSize selector wouldn't work with negative font size deltas -- it would actually *increase* the font size by 12 points. Thanks to Tom Bender. * WASTE would ignore weTagTransferMode when used as an HI command. * WEMatchAttributes() now works for the following attribute types, which were nonfunctional in earlier versions: weTagBackgroundColor weTagVerticalShift weTagDirection weTagLeftIndent weTagRightIndent weTagFirstLineIndent weTagSpaceBefore weTagSpaceAfter weTagLineSpacing * WEMatchAttributes now returns an error code when passed an unknown attribute selector. Previously, it will fail silently. * WEGetObjectOwner() now works for all objects, not just those inserted using WEInsertObject(). * WEGetObjectFrame() is now functional. * Vertical shifts had no effect on embedded objects. Now they do. * When reading or generating 'SOUP' or 'WEst' scraps on Intel, WASTE will now call CoreEndianFlipData() to endian-flip the embedded object data for resource types known to the system, such as 'snd'. * The built-in draw handler for 'snd' objects would draw a garbled icon on Intel machines. OTHER CHANGES: ============== * Reviewed the list of flavor types that can be passed to WEStreamRange() defined in "WASTE.h", adding comments about legacy flavors no longer recommended in WASTE 3.0, and listing known UTI equivalents. * WASTE.h now does a better job of listing attribute selectors that are either obsolete or currently unsupported in version 3.0. * Removed the last remnants of the FSSpec data type from the code. * Started reviewing the code for 64-bit cleanliness. -- marco -- It's not the data universe only, it's human conversation. They want to turn it into a one-way flow that they have entirely monetized. I look at the collective human mind as a kind of ecosystem. They want to clear cut it. They want to go into the rainforest of human thought and mow the thing down. From cnguyen at stata.com Fri May 11 11:35:33 2007 From: cnguyen at stata.com (Chinh Nguyen) Date: Fri, 11 May 2007 10:35:33 -0500 Subject: [WASTE-list] monospace text Message-ID: <69945B40-3E10-47C9-8DFC-06B61459B971@stata.com> My app has a built-in text editor for editing programs and it uses monospace, monostyle text. Is there a way to to set the inter character spacing so that each character is of a non fractional pixel width? I constrain window resizes to columns (like Terminal.app) and that's no longer working since the switch from WASTE 2 to WASTE 3. It would also be useful for tabbing because I tab based on characters and that's now broken too. In terms of constraining to a line height, that works OK. However, when I scroll down (I scroll by line height and character width rather than by pixel since my scrollbars track lines and columns, not pixels), I always see the bottom 2 pixel rows of the previous line to the top line of the page. My destrect and viewrect are the same except the destrect is really wide since I don't use word wrap. Which also leads me to this. In the WASTE sample, I see that in the calculation of the text rect, there's an InsetRect() of 3 pixels. However, when you resize the window, you still see the text drawn up to the edge of the scrollbars. Why is that? I do that same thing with my editor and as a test, I commented out the InsetRect() and saw that the text overwrites the scrollbars by you guessed it, 3 pixels. It's not that I want a 3 pixel gap next to my scrollbars, I'm just wondering why it's necessary to subtract 3 pixels from the right and bottom of the text rect. I think this logic has been there since older versions of WASTE. Also, in my Run Log I get the message: Exception thrown in function void WE3_File::OpenResFile(SInt8) (WE3_File.cp, line 272); error code = -39 when I WELoad() a text file. I figure it's a harmless message because the file opens just fine. -Chinh Nguyen cnguyen at stata.com From thykeeper at nerdshack.com Fri May 18 22:07:13 2007 From: thykeeper at nerdshack.com (Brother Josef) Date: Sat, 19 May 2007 09:07:13 +0700 Subject: [WASTE-list] drawing with views Message-ID: How are you supposed to obtain the CGContext from a HIView for use with the function WENewViewWithCGContext? As far as I know you can only get this information from a draw event but that doesn't seem appropriate to initialize the view upon receiving the views first attempt to draw. Or maybe that is not the intended use for the views API? Perhaps the question should be how do you bind waste to draw within a HIView quartz context? Currently I'm not sure where by default waste will be drawing within a composited window. thanks for your help. Regards, Josef -------------- next part -------------- An HTML attachment was scrubbed... URL: From marco.piovanelli at pobox.com Sun May 20 06:16:58 2007 From: marco.piovanelli at pobox.com (Marco Piovanelli) Date: Sun, 20 May 2007 12:16:58 +0200 Subject: [WASTE-list] monospace text In-Reply-To: <69945B40-3E10-47C9-8DFC-06B61459B971@stata.com> References: <69945B40-3E10-47C9-8DFC-06B61459B971@stata.com> Message-ID: <20070520101658.877880150@relay.pair.com> On Fri, 11 May 2007 10:35:33 -0500, Chinh Nguyen (cnguyen at stata.com) wrote: >My app has a built-in text editor for editing programs and it uses >monospace, monostyle text. > >Is there a way to to set the inter character spacing so that each >character is of a non fractional pixel width? I constrain window >resizes to columns (like Terminal.app) and that's no longer working >since the switch from WASTE 2 to WASTE 3. It would also be useful >for tabbing because I tab based on characters and that's now broken too. Is using a monospaced font like Courier not sufficient to get uniform (and non-fractional) character widths? >In terms of constraining to a line height, that works OK. However, >when I scroll down (I scroll by line height and character width >rather than by pixel since my scrollbars track lines and columns, not >pixels), I always see the bottom 2 pixel rows of the previous line to >the top line of the page. This is due to a new "feature" in WASTE 3.0. Please read on. >My destrect and viewrect are the same except the destrect is >really wide since I don't use word wrap. > >Which also leads me to this. In the WASTE sample, I see that in the >calculation of the text rect, there's an InsetRect() of 3 pixels. >However, when you resize the window, you still see the text drawn up >to the edge of the scrollbars. Why is that? I do that same thing >with my editor and as a test, I commented out the InsetRect() and saw >that the text overwrites the scrollbars by you guessed it, 3 pixels. WASTE 3.0 allows the text image to "bleed" outside of the destination rectangle by a certain margin, to avoid the unsightly clipping of (antialiased) glyphs, or the caret, near the edges of the destination rectangle. The default "bleed margin" is 3 pixels, but it can be adjusted on a view-by-view basis. Unfortunately, there is currently no way to do this through the procedural API. I'll fix this in the next release. >It's not that I want a 3 pixel gap next to my scrollbars, I'm just >wondering why it's necessary to subtract 3 pixels from the right and >bottom of the text rect. I think this logic has been there since >older versions of WASTE. The demo app has always added a three-pixel margin around the destination rectangle, but previous versions of WASTE wouldn't draw into the margin area. >Also, in my Run Log I get the message: > >Exception thrown in function void WE3_File::OpenResFile(SInt8) >(WE3_File.cp, line 272); error code = -39 > >when I WELoad() a text file. I figure it's a harmless message >because the file opens just fine. Yes, that is totally harmless. WASTE is just attempting to open the resource fork of the text file, looking for formatting resources. If there's no resource fork, it will just proceed to load the plain text. -- marco -- It's not the data universe only, it's human conversation. They want to turn it into a one-way flow that they have entirely monetized. I look at the collective human mind as a kind of ecosystem. They want to clear cut it. They want to go into the rainforest of human thought and mow the thing down. From marco.piovanelli at pobox.com Sun May 20 06:27:36 2007 From: marco.piovanelli at pobox.com (Marco Piovanelli) Date: Sun, 20 May 2007 12:27:36 +0200 Subject: [WASTE-list] drawing with views In-Reply-To: References: Message-ID: <20070520102736.1521403373@relay.pair.com> On Sat, 19 May 2007 09:07:13 +0700, Brother Josef (thykeeper at nerdshack.com) wrote: >How are you supposed to obtain the CGContext from a HIView for use >with the function WENewViewWithCGContext? As far as I know you can >only get this information from a draw event but that doesn't seem >appropriate to initialize the view upon receiving the views first >attempt to draw. You can pass NULL to WENewViewWithCGContext(), and set up the context later, at kEventControlDraw time, using WESetViewInfo() with the weCGContext selector. >Or maybe that is not the intended use for the views API? Perhaps the >question should be how do you bind waste to draw within a HIView >quartz context? Currently I'm not sure where by default waste will be >drawing within a composited window. Using WASTE within an HIView context is possible, but not trivial without access to the core C++ interface. Fortunately, the next release of WASTE will feature a built-in HIView wrapper. Please contact me privately if you'd like to test a pre-release version of this "HIWASTEView". -- marco -- It's not the data universe only, it's human conversation. They want to turn it into a one-way flow that they have entirely monetized. I look at the collective human mind as a kind of ecosystem. They want to clear cut it. They want to go into the rainforest of human thought and mow the thing down. From cnguyen at stata.com Mon May 21 19:14:44 2007 From: cnguyen at stata.com (Chinh Nguyen) Date: Mon, 21 May 2007 18:14:44 -0500 Subject: [WASTE-list] monospace text In-Reply-To: <20070520101658.877880150@relay.pair.com> References: <69945B40-3E10-47C9-8DFC-06B61459B971@stata.com> <20070520101658.877880150@relay.pair.com> Message-ID: <81185E6F-E51A-4DE5-B17D-7FD75ADD4340@stata.com> > Is using a monospaced font like Courier not sufficient to get > uniform (and non-fractional) character widths? No, and I only allow monospaced fonts. As a test, I measured several lines of text using WEGetLineWidth(). For example, with a 12 point Monaco font, I get a linewidth=7 charwidth=7.00 ab linewidth=14 charwidth=7.00 abcd linewidth=29 charwidth=7.25 aaaa linewidth=29 charwidth=7.25 1234 linewidth=29 charwidth=7.25 abcdefgh linewidth=58 charwidth=7.25 abcdefghijklmnopqrstuvwxyz0123456789!. linewidth=274 charwidth=7.22 abcdefghijklmnopqrstuvwxyz0123456789!.abcdefghijklmnopqrstuvwxyz01234567 89!. linewidth=547 charwidth=7.20 So you can see why my constraining logic no longer works. I had a similar problem with my output engine which uses Core Graphics for monospace text output and pixel relative drawing. I solved it by using CGContextSetCharacterSpacing() so that all my text lined up in uniform columns. I think I need something similar in WASTE 3. For now, I think I'll just measure a bunch of characters to get a decent char width stored as a float and use that for calculating the constraint. Thanks for the reply. -Chinh Nguyen cnguyen at stata.com From cnguyen at stata.com Tue May 22 12:35:01 2007 From: cnguyen at stata.com (Chinh Nguyen) Date: Tue, 22 May 2007 11:35:01 -0500 Subject: [WASTE-list] (no subject) Message-ID: <49837625-9149-489F-BEDB-EA13E7343D7F@stata.com> > For now, I think I'll just measure a bunch of characters to get a > decent char width stored as a float and use that for calculating > the constraint. Actually, I'll just Core Graphics to get me a character width but I just realized that that won't completely solve my problem because my default tab width for WESetDefaultTabWidth() is based on character width. So I really do need a way to set the character spacing. Or should I look at using a WETabList? -Chinh Nguyen cnguyen at stata.com From cnguyen at stata.com Tue May 22 14:04:03 2007 From: cnguyen at stata.com (Chinh Nguyen) Date: Tue, 22 May 2007 13:04:03 -0500 Subject: [WASTE-list] monospace text Message-ID: <72F6A10E-D098-41E0-9F31-9EA5761C2966@stata.com> Uh, never mind. I forgot what a Fixed is... WESetDefaultTabWidth() can handle my fractional char width just fine and so can my constraining code. Sorry for the noise. -Chinh Nguyen cnguyen at stata.com From thykeeper at nerdshack.com Wed May 23 10:15:36 2007 From: thykeeper at nerdshack.com (Brother Josef) Date: Wed, 23 May 2007 21:15:36 +0700 Subject: [WASTE-list] WASTE 3.0 ClickLoop Message-ID: <7D4BD33F-59D6-4819-83C3-AAF33B3AEA5C@nerdshack.com> I just noticed the click loop is not triggering in 3.0. Has it been removed? I'm calling waste from a composited window if that would make any difference. Regards, Josef -------------- next part -------------- An HTML attachment was scrubbed... URL: From marco.piovanelli at pobox.com Thu May 24 09:40:14 2007 From: marco.piovanelli at pobox.com (Marco Piovanelli) Date: Thu, 24 May 2007 15:40:14 +0200 Subject: [WASTE-list] WASTE 3.0 ClickLoop In-Reply-To: <7D4BD33F-59D6-4819-83C3-AAF33B3AEA5C@nerdshack.com> References: <7D4BD33F-59D6-4819-83C3-AAF33B3AEA5C@nerdshack.com> Message-ID: <20070524134014.395970113@relay.pair.com> On Wed, 23 May 2007 21:15:36 +0700, Brother Josef (thykeeper at nerdshack.com) wrote: >I just noticed the click loop is not triggering in 3.0. Has it been >removed? Yes, the click loop callback is not functional in WASTE 3.0. Here's the complete list of WESetInfo() selectors that aren't supported in version 3.0: weAutoScrollDelay weBusyProc weBusyInterval weCharByteHook weCharToPixelHook weClickLoop weCurrentDrag weDrawTextHook weDrawTSMHiliteHook weEraseHook weFontFamilyToNameHook weFontNameToFamilyHook weHiliteDropAreaHook weLineBreakHook wePixelToCharHook weText weTranslateDragHook weTranslucencyThreshold weTSMDocumentID weURLHint weWordBreakHook Some of these I may re-enable in future releases, if there's any interest; some are gone for good. The click loop is one of the callbacks I could reinstate, but first I'd like to know what you need it for. In many cases, click loops were used to detect autoscrolling during mouse tracking. For that purpose, you really want to use a scroll callback instead. Or even better, use the soon-to-be- available HIWASTEView, embed it into an HIScrollView, and you'll be all set. -- marco -- It's not the data universe only, it's human conversation. They want to turn it into a one-way flow that they have entirely monetized. I look at the collective human mind as a kind of ecosystem. They want to clear cut it. They want to go into the rainforest of human thought and mow the thing down. From manistyman at yahoo.com Thu May 24 13:26:50 2007 From: manistyman at yahoo.com (Richard Laws) Date: Thu, 24 May 2007 10:26:50 -0700 (PDT) Subject: [WASTE-list] WASTE 3.0 ClickLoop In-Reply-To: <20070524134014.395970113@relay.pair.com> Message-ID: <671622.13327.qm@web60215.mail.yahoo.com> One of the reasons I set aside my WASTE-view-within-a-HIScrollView version of my HIView was that I wanted a way of splitting the view to be able to consult (and perhaps modify, copy, paste, etc.) two or more sections of the text in the same HIViewRef. An HIScrollView's text subview would have to respond to scrollable "scroll to" events with WEScroll. This is where the concept of WEViewReference might come to the rescue. Consider the following: A parent HIViewRef is created which creates a WASTE instance. It then creates and embeds one or more HIScrollViews, each containing a 'text' HIViewRef containing a WEViewReference created with that single WASTE instance. My question is this: Would the multiple views work independently when receiving scroll to events? For example, I have two views of the same WEReference. I've set my current WEViewReference to the lower of the two. I click that view's scroll bar. I've got to respond to that event (sent by the parent HIScrollView) with WEScroll. Would the upper view also scroll? After all, it's the same WEReference being told to scroll. Or, not being the current WEViewReference, does it remain stationary and stay that way when made current again? Sorry to be so windy. Thanks, Richard --- Marco Piovanelli wrote: > (...) Or even better, use the > soon-to-be- > available HIWASTEView, embed it into an > HIScrollView, and > you'll be all set. ____________________________________________________________________________________Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more. http://mobile.yahoo.com/go?refer=1GNXIC From marco.piovanelli at pobox.com Thu May 24 16:59:32 2007 From: marco.piovanelli at pobox.com (Marco Piovanelli) Date: Thu, 24 May 2007 22:59:32 +0200 Subject: [WASTE-list] Multiple views, shared controller (was: Re: WASTE 3.0 ClickLoop) In-Reply-To: <671622.13327.qm@web60215.mail.yahoo.com> References: <20070524134014.395970113@relay.pair.com> <671622.13327.qm@web60215.mail.yahoo.com> Message-ID: <20070524205932.778978955@relay.pair.com> On Thu, 24 May 2007 10:26:50 -0700, Richard Laws (manistyman at yahoo.com) wrote: >One of the reasons I set aside my >WASTE-view-within-a-HIScrollView version of my HIView >was that I wanted a way of splitting the view to be >able to consult (and perhaps modify, copy, paste, >etc.) two or more sections of the text in the same >HIViewRef. An HIScrollView's text subview would have >to respond to scrollable "scroll to" events with >WEScroll. This is where the concept of >WEViewReference might come to the rescue. Yes, that's the kind of scenario WASTE views were designed for. >Consider the following: A parent HIViewRef is created >which creates a WASTE instance. It then creates and >embeds one or more HIScrollViews, each containing a >'text' HIViewRef containing a WEViewReference created >with that single WASTE instance. You probably want a SplitView (possibly modeled after the sample code in /Developer/Examples/Carbon/SplitView) containing two HIScrollViews, each of which, in turns, contains your WASTE-based HIView. Each WASTE HIView would keep its own WEViewReference, but they would share the same controller (WEReference). >My question is this: Would the multiple views work >independently when receiving scroll to events? Yes. Each WEViewReference has its own view and destination rectangles, and can scroll independently of the other. >For example, I have two views of the same WEReference. >I've set my current WEViewReference to the lower of >the two. I click that view's scroll bar. I've got to >respond to that event (sent by the parent >HIScrollView) with WEScroll. That WEScroll takes a WEReference, rather than a more natural WEViewReference, is only a historical artifact -- the original WASTE API wasn't designed for strict model-view-controller separation, but to be a drop-in replacement for TextEdit. But internally, WEScroll, and many other view-centric APIs, are routed to the "current" view, which you can change at any point with WESetCurrentView(). In other words, instead of introducing a bunch of parallel view-centric APIs (WEScrollView, WESetViewDestRect, WESetViewViewRect, WEAdjustCursorInView, etc.) that duplicate the existing controller-centric APIs, I thought it simpler to maintain the old APIs, with the implicit stipulation that they operate on the current view. >Would the upper view also scroll? No. >Or, not being the current WEViewReference, does it remain >stationary and stay that way when made current again? Yes. -- marco -- It's not the data universe only, it's human conversation. They want to turn it into a one-way flow that they have entirely monetized. I look at the collective human mind as a kind of ecosystem. They want to clear cut it. They want to go into the rainforest of human thought and mow the thing down. From manistyman at yahoo.com Thu May 24 18:18:18 2007 From: manistyman at yahoo.com (Richard Laws) Date: Thu, 24 May 2007 15:18:18 -0700 (PDT) Subject: [WASTE-list] Multiple views, shared controller (was: Re: WASTE 3.0 ClickLoop) In-Reply-To: <20070524205932.778978955@relay.pair.com> Message-ID: <64075.62610.qm@web60224.mail.yahoo.com> Thank you! Now if only I could stop getting that param error with WENewViewWithCGContext(NULL, ...). Richard --- Marco Piovanelli wrote: > On Thu, 24 May 2007 10:26:50 -0700, > Richard Laws (manistyman at yahoo.com) wrote: > > > >One of the reasons I set aside my > >WASTE-view-within-a-HIScrollView version of my > HIView > >was that I wanted a way of splitting the view to be > >able to consult (and perhaps modify, copy, paste, > >etc.) two or more sections of the text in the same > >HIViewRef. An HIScrollView's text subview would > have > >to respond to scrollable "scroll to" events with > >WEScroll. This is where the concept of > >WEViewReference might come to the rescue. > > Yes, that's the kind of scenario WASTE views were > designed for. > > >Consider the following: A parent HIViewRef is > created > >which creates a WASTE instance. It then creates > and > >embeds one or more HIScrollViews, each containing a > >'text' HIViewRef containing a WEViewReference > created > >with that single WASTE instance. > > You probably want a SplitView (possibly modeled > after > the sample code in > /Developer/Examples/Carbon/SplitView) > containing two HIScrollViews, each of which, in > turns, > contains your WASTE-based HIView. Each WASTE HIView > would keep its own WEViewReference, but they would > share > the same controller (WEReference). > > >My question is this: Would the multiple views work > >independently when receiving scroll to events? > > Yes. Each WEViewReference has its own view and > destination > rectangles, and can scroll independently of the > other. > > >For example, I have two views of the same > WEReference. > >I've set my current WEViewReference to the lower of > >the two. I click that view's scroll bar. I've got > to > >respond to that event (sent by the parent > >HIScrollView) with WEScroll. > > That WEScroll takes a WEReference, rather than a > more natural WEViewReference, is only a historical > artifact -- the original WASTE API wasn't designed > for > strict model-view-controller separation, but to be a > drop-in replacement for TextEdit. But internally, > WEScroll, and many other view-centric APIs, are > routed > to the "current" view, which you can change at any > point > with WESetCurrentView(). > > In other words, instead of introducing a bunch of > parallel view-centric APIs (WEScrollView, > WESetViewDestRect, > WESetViewViewRect, WEAdjustCursorInView, etc.) that > duplicate > the existing controller-centric APIs, I thought it > simpler > to maintain the old APIs, with the implicit > stipulation > that they operate on the current view. > > >Would the upper view also scroll? > > No. > > >Or, not being the current WEViewReference, does it > remain > >stationary and stay that way when made current > again? > > Yes. > > > -- marco > > -- > It's not the data universe only, it's human > conversation. > They want to turn it into a one-way flow that they > have entirely > monetized. I look at the collective human mind as a > kind of > ecosystem. They want to clear cut it. They want to > go into the > rainforest of human thought and mow the thing down. > > ____________________________________________________________________________________ Park yourself in front of a world of choices in alternative vehicles. Visit the Yahoo! Auto Green Center. http://autos.yahoo.com/green_center/ From thykeeper at nerdshack.com Thu May 24 20:31:38 2007 From: thykeeper at nerdshack.com (Brother Josef) Date: Fri, 25 May 2007 07:31:38 +0700 Subject: [WASTE-list] waste view Message-ID: <7E239BE2-4285-42F1-A901-99290B44F513@nerdshack.com> Sorry I didn't respond in my other posts, I just discovered my spam filter started tossing out the waste list... on setting up waste as a HIView... I don't know what i'm doing to upset WASTE but calling WENewViewWithCGContext with a predefined CGContext or leaving the field null and setting it later caused crashing (in InvokeWEUndoUPP?). I'm using the 3.0.2. I also noticed the waste demo in the package is "damaged or incomplete". maybe some bugs? Do i need to setup a WEView to prevent it from drawing "over" the current context? for example, say an image was draw over the text the next time waste flashes the carrot it will draw over the text, white background and all. Also, i would like to comment on the confusion converting between coordinate systems. Using HIView and Quartz origins are often not what waste expects and in the case of WEAdjustCursor I have no idea where waste thinks it is. With trial and error I got most of it worked out, but it sure was confusing. What coordinate system does waste prefer? i feel like it's using both Quartz and QD... otherwise it seems to be creating a functional HIView as expected. thanks for your ideas. Regards, Josef -------------- next part -------------- An HTML attachment was scrubbed... URL: From marco.piovanelli at pobox.com Fri May 25 05:53:43 2007 From: marco.piovanelli at pobox.com (Marco Piovanelli) Date: Fri, 25 May 2007 11:53:43 +0200 Subject: [WASTE-list] Damaged demo in the 3.0.2 distribution In-Reply-To: <7E239BE2-4285-42F1-A901-99290B44F513@nerdshack.com> References: <7E239BE2-4285-42F1-A901-99290B44F513@nerdshack.com> Message-ID: <20070525095343.1081174667@relay.pair.com> Some people noticed that the demo application in the 3.0.2 distribution won't launch -- the Finder complains that it is "damaged or incomplete". My bad. I renamed the .app bundle immediately before creating the disk image, but that doesn't work unless I also rename the executable and update the Info.plist file. I guess that's another instance of being spoiled by the classic Mac OS... Anyway, I've just uploaded a fixed disk image: Nothing changed except the names. -- marco -- It's not the data universe only, it's human conversation. They want to turn it into a one-way flow that they have entirely monetized. I look at the collective human mind as a kind of ecosystem. They want to clear cut it. They want to go into the rainforest of human thought and mow the thing down. From marco.piovanelli at pobox.com Fri May 25 12:10:19 2007 From: marco.piovanelli at pobox.com (Marco Piovanelli) Date: Fri, 25 May 2007 18:10:19 +0200 Subject: [WASTE-list] [ANN] WASTE 3.1b1 now available Message-ID: <20070525161019.1485105388@relay.pair.com> A beta version of WASTE 3.1 is now available for download: The biggest change in this release is the addition of a built-in HIView wrapper, dubbed "HIWASTEView". In fact, the only new API is this: EXTERN_API ( OSStatus ) HIWASTEViewCreate ( const HIRect * inViewBounds, OptionBits inWASTEOptions, HIViewRef * outHIViewRef ) ; HIWASTEView currently requires Mac OS X 10.4, and only works in compositing windows. It supports a number of goodies, including: 1. Embedding in an HIScrollView. 2. Drag and drop. 3. Contextual menus. 4. Accessibility. 5. Services. 6. Font panel. The new SDK contains a radically simplified version of the old WASTE demo, which uses HIWASTEView. -- marco -- It's not the data universe only, it's human conversation. They want to turn it into a one-way flow that they have entirely monetized. I look at the collective human mind as a kind of ecosystem. They want to clear cut it. They want to go into the rainforest of human thought and mow the thing down. From marco.piovanelli at pobox.com Mon May 28 12:35:00 2007 From: marco.piovanelli at pobox.com (Marco Piovanelli) Date: Mon, 28 May 2007 18:35:00 +0200 Subject: [WASTE-list] waste view In-Reply-To: <7E239BE2-4285-42F1-A901-99290B44F513@nerdshack.com> References: <7E239BE2-4285-42F1-A901-99290B44F513@nerdshack.com> Message-ID: <20070528163500.2013139206@relay.pair.com> On Fri, 25 May 2007 07:31:38 +0700, Brother Josef (thykeeper at nerdshack.com) wrote: >Sorry I didn't respond in my other posts, I just discovered my spam >filter started tossing out the waste list... > >on setting up waste as a HIView... > >I don't know what i'm doing to upset WASTE but calling >WENewViewWithCGContext with a predefined CGContext or leaving the >field null and setting it later caused crashing (in >InvokeWEUndoUPP?). I'm using the 3.0.2. Could you please verify whether you still get this crash with the latest beta (3.1b1)? If you still crash, could you please send me the crash log? >Do i need to setup a WEView to prevent it from drawing "over" the >current context? for example, say an image was draw over the text the >next time waste flashes the carrot it will draw over the text, white >background and all. You can prevent WASTE from erasing the background to white by setting the alpha of the background color to 0.0. This is what HIWASTEView does when drawing to a compositing window. It makes it very easy to have, say, a picture background under the text. WEViewReference view; ATSURGBAlphaColor transparentColor = {0.0, 0.0, 0.0, 0.0}; OSStatus err; view = WEGetCurrentView(controller); err = WESetViewInfo(weBackgroundColor, &transparentColor, view); >Also, i would like to comment on the confusion converting between >coordinate systems. Using HIView and Quartz origins are often not >what waste expects and in the case of WEAdjustCursor I have no idea >where waste thinks it is. In general, WASTE expects local Quickdraw coordinates. WEAdjustCursor() is an exception -- it expects global coordinates, as it was documented back in 1998. The HIView model is likely a source of additional confusion, since it introduces more coordinate systems, view coordinates and window coordinates (not the same as Quickdraw window coordinates). Fortunately, the built-in HIView wrapper available in WASTE 3.1 handles all the coordinate translations for you, and makes APIs like WEAdjustCursor largely unnecessary. -- marco -- It's not the data universe only, it's human conversation. They want to turn it into a one-way flow that they have entirely monetized. I look at the collective human mind as a kind of ecosystem. They want to clear cut it. They want to go into the rainforest of human thought and mow the thing down.