Image.
On Image / Off Image and Mixed Image
alternate image....Currently the default behaviour is to use the
OnState, OffState and Mixedstate image from the theme. I will alter this so it will first take it from the item's OnState, OffState or Mixedstate image. If it does not have one it will take it from the Theme.
Questions about the responder chain, general and specific. I generally manually insert CPViewController instances in the responder chain during init or awakeFromCib using:
[self setNextResponder:[self view]];
var subviews = [[self view] subviews];
for (var i = 0; i < [subviews count]; i++)
{
var subview = subviews[i];
[subview setNextResponder:self];
}
I have an open issue about missing automatic responder chain support and intend something like this be added, but have been uncertain if there are configurations in which this isn’t sufficient. The following appears to be one…
We have a the following view hierarchy:CPWindowCPSplitViewCPDetailView (the right side of the split view)ENQLayoutView (a CPBox subclass)ENQWidgetView (another CPBox subclass, multiple instances)
Each has their own controller.
The widgets are moveable and resizeable.
Everything but the widget view is created statically in IB.
The canvas and widget views have CPMenus associated with their menu properties.
Tracking areas inside the widget views are used to change cursors when the mouse is over them, and to allow dragging and resizing to alter their positions on the canvas.
Some instances of the widgets will contain CPTextViews which have their own cursor management needs, obviously. It is necessary to toggle move/resize mode on and off using a modifier key as a signal. The proper way to do this is overriding flagsChanged: in the view controller, ideally that for the widget, or perhaps the canvas.
In this instance, nothing below the splitView controller appears to be in the responder chain - flagsChanged: is called for the splitView controller, but nothing below it in the hierachy. Furthermore, when the canvas or widget controllers are inserted into the responder chain, the context menu’s for them are no longer available.
Is anyone able to explain the responder chain in this context?
flagsChanged: in the splitView controller, then post a notification which the canvas controller listens for and sets/unsets a property indicating the modifier key state. It works, and may even be the best approach, but I need to understand what’s happening in the splitView responder chain. I’m reluctant to issue a PR that closes the responder chain issue until I have a better understanding
@daboe01 That definitely goes into the code snippet vault for future use.
In this case, the Apple-recommended approach is[textStorage setAttributes:@{} range:selectedRange];
[textStorage processEditing];
This in a method in the textView’s controller, wired to the menuItem.
I was hoping to keeping everything for the menu in the IB domain, but not possible given the missing firstResponder implementation for CPTextView. Not the end of the world, and another little thing to fix once the immediate project has stabilized.
Has anyone tried using Cappuccino in fullscreen mode?[viewInstance enterFullScreenMode] and
the browser FullScreen API both seem to either make essential parts of the DOM we construct inaccessible (resulting in random functionality being disabled) or otherwise prevent our runtime from working properly.
It’s not yet clear to me if this is a difficult problem to resolve or not.
https://michaelbach.de/ot/FrACT10/capp/
there's a Fullscreen button and it works well for me.
I was not aware that Cappuccino offers fullscreen help, a mixed blessing in hindsight :), so I'm using (how do I paste multiline code?):
(void) fullScreenOn: (BOOL) onOff {
var element = document.documentElement;
if (onOff) {if(element.requestFullscreen) element.requestFullscreen(); else if(element.mozRequestFullScreen) element.mozRequestFullScreen(); else if(element.webkitRequestFullscreen) element.webkitRequestFullscreen(); else if(element.msRequestFullscreen) element.msRequestFullscreen();} else {
if(document.exitFullscreen) document.exitFullscreen(); else if(document.mozCancelFullScreen) document.mozCancelFullScreen(); else if(document.webkitExitFullscreen) document.webkitExitFullscreen(); else if(document.msExitFullscreen) document.msExitFullscreen();}
}(BOOL) isFullScreen {
var full_screen_element = document.fullscreenElement || document.webkitFullscreenElement || document.mozFullScreenElement || document.msFullscreenElement || null;
if(full_screen_element === null)// If no element is in full-screenreturn false;else
return true;}
Sorry for the horrible result.
Xcode still supports third-party language plugins. Work-in-progress support for Objective-J is available at: https://github.com/enquora/xcode-cappuccino
Selector highlighting is still miminal, but shouldn’t be terribly difficult to polish.
The installer uses xcode-select to determine the active version of Xcode and install language support for it. Because the language support assets must(?) be within the Xcode bundle, they must be re-installed when Xcode is updated, and when the active version is changed.
.h support was included in the original xclangspec files this used as a starting point. You mentioned last year this might be a supported feature of our compiler.
In Xcode, in the file inspector, set "Type" to "Objective-C Source" rather than than "Default – Plain text".
Alternatively, use Xcode>Editor>Syntax Coloring>Objective-C.
The former method has the advantage that it can be applied to all Objective-J files at once if you select them in the Navigator.
@michaelbach It appears the Xcode editor is also using the lexing/parsing instructions in xcclangspec to create auto-complete suggestions. I’m guessing this is a default, and the presence of sourcekit-lsp (for C, C++ and Objective equivalents) is a trigger to use the LSP.
Further experience needed with this. An xclangspec will be needed for Jakefiles too. This doesn’t look nearly as daunting as for Objective-J itself.