Quartz Builder 1.3 second display issue

Swiftlikeninja's picture

Hey, Im trying to build out an application that is using a second display. in the old version of quartz builder everything worked without an issue, but with 1.3, the app loads on the primary display only, no matter what display its set to in quartz builder. Can anyone else verify this issue or assist me in what I am doing wrong?

gtoledo3's picture
Re: Quartz Builder 1.3 second display issue

Verified. Too bad it didn't get alpha tested to iron this stuff out, it's a complex app (maybe there wasn't time? No clue.)

Swiftlikeninja's picture
Re: Quartz Builder 1.3 second display issue

At first I just thought I was doing something wrong. I'm stuck using the previous released until this gets fixed unfortunately... Everything else appears to work perfectly.

jstrecker's picture
Re: Quartz Builder 1.3 second display issue

@Swiftlikeninja -- Sorry about that. The behavior of fullscreen has definitely changed between 1.2 and 1.3 that was not intentional. We're investigating now. As a workaround, you can use the QB protocol Fullscreen output, as in the attached composition. When you have built the composition with Fullscreen Display set to Display 1, it fullscreens to the secondary monitor.

@gtoledo3 -- Why do you assume that we didn't alpha test QuartzBuilder 1.3? Anyway, we wanted to release QuartzBuilder 1.3 as soon as it became useful to people. At that point, there wasn't any reason to give a select group of users early access.

PreviewAttachmentSize
QB fullscreen test.qtz54.01 KB

gtoledo3's picture
Re: Quartz Builder 1.3 second display issue

Is it an assumption? I believe it to be correct. I'd always recieved alpha versions of qb to alpha test in the past. There's still an alpha forum here, as well. Neither method was used for the past iteration of qb. When I was aware a release was imminent I enquired and wasn't given a copy to test.

Maybe there's some issue of semantics, but IMO, qb 1.3 wasn't alpha tested.

volkerk's picture
Re: Quartz Builder 1.3 second display issue

for me toggling to fullscreen goes back to main screen (Snow Leopard).

In QB 1.2, toggling to fullscreen uses whatever screen the window is positioned in. which is a great way of doing it.

jstrecker's picture
Re: Quartz Builder 1.3 second display issue

@Swiftlikeninja, @gtoledo3, @volkerk, anyone else who's interested --

Here's a new version of QuartzBuilder. (Alpha, beta, whatever letter you like. You must be registered as a beta tester to see it -- that's under your kineme.net account settings.)

Any more issues with fullscreen? If not, I'll do the actual release.

gtoledo3's picture
Re: Quartz Builder 1.3 second display issue

jstrecker wrote:
Alpha forum? :)

SIGH.

YES JAYMIE.

The alpha forum has apparently been deleted. Ask someone if you aren't aware.

You didn't think to ask before posting a link that attempts to indicate that there wasn't one? What is that link that directs to nothing supposed to show? Not many had access to that anyway, so most users would get zilch anyway.

QB 1.3 was not alpha tested the same way as previous iterations. Whether these issues people are reporting could have been avoided is another matter. Who knows if they would have been caught or not.

:-)

jstrecker's picture
Re: Quartz Builder 1.3 second display issue

gtoledo3 wrote:
these issues people are reporting

What other issues have been reported?

If the alpha forum link is misleading, I didn't intend it. The alpha forum has not (to my knowledge) been used since I started working with Kineme over a year ago. So I did ask someone because I was not aware.

gtoledo3's picture
Re: Quartz Builder 1.3 second display issue

jstrecker wrote:
gtoledo3 wrote:
these issues people are reporting

What other issues have been reported?

There are the display issues, there are issues with the way AlphaBlend.plugin is managed (imo), there are issues with the way some alpha plugins are handled (Data Tools alpha, re: splitters, whether it was "decided" it was reasonable to have it work or not), there are issues with the Template composition still not having been replicated/replaced/backwards engineered (like what, 2 years later?) to work how it originally did, there are issues with window coords not getting updated with mouse how they originally would, there are issues with structures not rendering correctly (this may be a QC framework issue, but I wonder if it couldn't have been worked around had someone noticed it)... this is after thinking about it for around 10 seconds. I'm fairly sure I could go deeper. Maybe not.

I understand that reads really tersely. It's because I'd alpha-d all previous versions, was aware of a litany of issues, heard of the coming release, and gave a head's up that I was available to give it a run through like has happened every other time. A lot of the features, defaults, etc., that are in QB are things that I directly suggested in back and forths with cwright, and I have long technical explanations, and back and forth logic of "why" stuff actually is how it is, that predate your involvement with it at all (not impugning your talents at all. You are one sharp coder. I just don't think you have the breadth of knowledge with QC, or QB to think that this wouldn't end up with some major oversights). You simply are not making qtz's everyday, nor QB apps. I had hoped it would be released and be tight, but that didn't happen. I put the offer to help out there.

smokris's picture
Re: Quartz Builder 1.3 second display issue

gtoledo3 wrote:
There are the display issues

Fixed in http://kineme.net/release/QuartzBuilder/20111118

gtoledo3 wrote:
there are issues with the way AlphaBlend.plugin is managed (imo)

Work in progress, as we already discussed off-forum.

gtoledo3 wrote:
there are issues with the way some alpha plugins are handled (Data Tools alpha, re: splitters, whether it was "decided" it was reasonable to have it work or not)

The way the prerelease build of DataTools handled splitters was an experiment not intended for production use.

gtoledo3 wrote:
there are issues with the Template composition still not having been replicated/replaced/backwards engineered (like what, 2 years later?) to work how it originally did

See QuartzBuilder Documentation, section titled "QuartzBuilder Template".

gtoledo3 wrote:
there are issues with window coords not getting updated with mouse how they originally would

You're referring to http://kineme.net/node/9737 ? As of Snow Leopard, the built-in Mouse patch no longer updates when the containing window is unfocused, like it did in Leopard. This behavior change is due to Quartz Composer, not QuartzBuilder.

gtoledo3 wrote:
there are issues with structures not rendering correctly (this may be a QC framework issue, but I wonder if it couldn't have been worked around had someone noticed it)...

You're referring to http://kineme.net/node/10803 ? The problem there is with some stock QC patches not behaving properly in Lion in 32-bit mode (try running the composition in the QC editor in 32-bit mode --- same problem occurs there). QuartzBuilder can't do anything about that (except avoid the 32-bit runtime, which as of 1.3 it can now do).

smokris's picture
Re: Quartz Builder 1.3 second display issue

gtoledo3 wrote:
The alpha forum has apparently been deleted. Ask someone if you aren't aware.

The Alpha forum wasn't deleted, it was just hardly ever used. Here's the correct link: http://kineme.net/forum/Alpha (sorry, @jstrecker, I gave you the wrong link when you asked earlier). Last used March 2009.

gtoledo3's picture
Re: Quartz Builder 1.3 second display issue

smokris wrote:
gtoledo3 wrote:
There are the display issues

Fixed in http://kineme.net/release/QuartzBuilder/20111118

gtoledo3 wrote:
there are issues with the way AlphaBlend.plugin is managed (imo)

Work in progress, as we already discussed off-forum.

Sure. I'm simply stating, that had their been alpha testing, like most other production apps, and like previous versions of QB, the issue would have, perhaps, been addressed already.

Both the display bug, and the AlphaBlend.plugin issue (that, I think is a bug, and define it as so. QB is supposed to load all used patches that a user uses in a qtz. This is how it has been touted. When cwright fixed this with GLTools, it worked very well (we've discussed the times it could possibly not work, but it's overall, solid). That behavior was subsequently broken. As you know, I had to wrangle considerably to get this to even be considered an issue, when in fact, it's the most recurring problem conveyed to me by users of QB. I've had dozens of conversations about this when people can't figure out why things don't look right. It's a big surprise to users, and it immediately makes it seem as though QB is broken, potentially the very first time a user compiles. That's not good at all.

(Side issue, but I think the removal of AlphaBlend from GLTools was ill advised without any kind of prompting of users, that compositions are opening differently. That bites me to this day. Once the blend port code was brought up to date, I don't really think it needed to be split out and made to be a separate plugin, no matter how many people whined about having an old version loaded, meant to work in Leopard. What you did was to actually screw attentive users, and provide no way of letting a newer user who looks at an old comp, that something isn't restoring right. There were prompts for deprecated stuff in GL Tools before. Could this not have been done?)

It's great the work is in-progress to fix the stuff though. These are kind of the fixes I was looking forward to with this release, because they're the issues I've had, and that kind of make QB seem a little flaky to me, and in projects where multiple people are building the same app. There basically has to be a checklist of things to consider that QB may not be doing correctly, that an op would have to go through.

smokris wrote:
gtoledo3 wrote:
there are issues with the way some alpha plugins are handled (Data Tools alpha, re: splitters, whether it was "decided" it was reasonable to have it work or not)

The way the prerelease build of DataTools handled splitters was an experiment not intended for production use.

True, but I'm pretty darn sure it could have been adjusted to make the splitters work reasonably and load them, either by analyzing the graph for ports with the right types, or backing the insert splitters with an xml file, or? Would it have fattened the code? Been ugly? Ok, but it would have worked, and maybe solved other problems, like there not being a K3D type splitter.

The implementation was iffy, but I think many users would have loved this function, and it could have worked as well as other "iffy" things.

Back to K3D splitters - I mean, you can still make an insert splitter off of a K3D port, and it turns into a non-existent splitter instead of a virtual, throwing exceptions, etc. It may have just been a good idea to have kept those Data Tools splitters, added a K3D splitter type as well, and had less chance for weird exceptions, though it would necessitate Data Tools being a resource.

smokris wrote:
gtoledo3 wrote:
there are issues with the Template composition still not having been replicated/replaced/backwards engineered (like what, 2 years later?) to work how it originally did

See QuartzBuilder Documentation, section titled "QuartzBuilder Template".

Ok. That says nothing to me Steve. It's really not working because we farted out on doing it and making a decision on whether to mod the actual file (since it's no longer a dynamic thing), or to reverse engineer it from scratch. At some point, it got abandoned. To me, "template" functionality, is distinct from "protocol" functionality. Heck, to anyone. Two different things, though intertwined.

Then, we were talking about being able to pull the whole arrangement of patches out of the Library, all connected, non-macroed. Not a bad idea. Went nowhere. Again... it just seemed easier to blame it on QC changing (imo), and not make it work slickly for people.

smokris wrote:
gtoledo3 wrote:
there are issues with window coords not getting updated with mouse how they originally would

You're referring to http://kineme.net/node/9737 ? As of Snow Leopard, the built-in Mouse patch no longer updates when the containing window is unfocused, like it did in Leopard. This behavior change is due to Quartz Composer, not QuartzBuilder.

Yes, but that's the built in. It could be swapped during compile for something that works. Instead, a whole swarth of function that was available in Leopard is no longer there.

smokris wrote:
gtoledo3 wrote:
there are issues with structures not rendering correctly (this may be a QC framework issue, but I wonder if it couldn't have been worked around had someone noticed it)...

You're referring to http://kineme.net/node/10803 ? The problem there is with some stock QC patches not behaving properly in Lion in 32-bit mode (try running the composition in the QC editor in 32-bit mode --- same problem occurs there). QuartzBuilder can't do anything about that (except avoid the 32-bit runtime, which as of 1.3 it can now do).

I see what you mean about it being a very complex issue when the 32 bit runtime is totally screwed in Lion with structures, but could the broken aspects have been shimmed, or could we have pulled from past, known to be working frameworks? I'm tending to think so, even though it's not how QB has worked, in the past. It's a skanky thing anyway, it's not as if anyone is going to be calling out the method/or hacks, if the end thing works. I think actually loading the old, working frameworks in that context, instead of linking to the new broken ones -frocked with some pain in the butt factor, may have been tenable?

It's just a head scratcher to me, that with such a complex app, where you used to really go through lengths to iron stuff out, that it was just dropped out there like this, even after I attempted to go "hey duders, what is UP here?" I understand the want to knock it out of the park, sans help, but I think cwright was quite prudent to send me copies to work over in the past.

I spend the time to write this because I care :-) If I didn't think kineme was great, if I didn't love working with you on other endeavors, I wouldn't be spending time writing this.

This update really has nothing that makes it worthwhile to update for, and that pains me to say. This isn't a slam. The hand writing was kind of on the wall. I hope it improves in the future, it has so much potential.

cwright's picture
Re: Quartz Builder 1.3 second display issue

I think you're exaggerating some points, and over-simplifying many others (amid some well-founded points too). I shan't quote because it's a bit cumbersome.

You speak often of the alpha-blend-mode-that-worked build of QB. I'm not sure such a thing ever existed, and if it did it was because I hacked it in (an "M" version, if you will). Assuming I made that, I obviously wasn't satisfied with the implementation because it never got committed. (checking my old repository, I have no outstanding changes, so I didn't even keep them around locally - that's saying something). To expect smokris et al. to conjure up the missing hack I made and never saved isn't a reasonable expectation - I had no learning curve with the code, because I wrote it. They're at a distinct disadvantage from the start. It would be mutually favorable to let this point go (it'll get fixed someday, and if not it's not as severe as you make it out to be).

Further, alpha blend mode being split was a good idea. it was causing problems for a number of users (primarily due to bugs I wasn't able to sort out). Similar problems have had Apple forcibly uninstall plugins on upgrades (!), so by splitting it out it at least meant that the rest of GLools would remain. That's extraordinarily prudent, in my opinion. (There is a Radar classification deemed "Third Party to resolve", which is basically "Not Apple's Problem" -- I try to give smokris rough heads up when I spot something kineme-centric that ends up on that list, and he has responded swiftly enough that no one has actually noticed - it's a shame no one notices when things work).

Further further, Alpha blend is an enormous hack to save people from needing to premultiply. This is trivial to do once you figure it out, it's just that no one wants to figure it out and/or it's tricky to know when to do it. I don't know that any uses of it are actually necessary (though it could be very convenient).

Splitters are a tricky topic because of the internal implementation. I spent years trying to find a good way to change them, and didn't succeed. It's unfair to expect smokris to suddenly wave his hands and have a flawless implementation that shims all he right bits. Nobody wants custom splitter patches, they want the built-in flavor to Just Work. Getting to that point is non-trivial.

The template is another difficult problem. Pulling out a full-formed graph that behaves nicely is difficult (the KinemeCore spliter functionality I added was the result of a huge amount of trial-and-error and R&D - since KC's free, it was a colossal financial loss for Kosada, but it might have made it up in terms of time saved internally, to say nothing of external uses). Again, the magic shim wand sounds seductively simple, but it's actually quite difficult to pull off well.

More magic shim want stuff. Swapping patches out on the fly? that's incredibly dangerous and difficult to do, and I only ever pulled it off with just 1 patch, which required me to disassemble it, annotate it, and then re-implement it with bug-for-bug compatibility + the modified behavior. Nobody does that in real life, I'm just OCD. Seriously, that's the kind of stuff people who write exploits, rootkits, and software cracks do. It's not a garden-variety programmer skill.

There's no practical way to load the "old frameworks" - that would require distribution of apple-owned code, which would be a terrible idea (and illegal too).

You point out things that were abandoned/dropped on the floor. The date that happened was probably Feb 1, 2010. Keep in mind that I spent virtually every waking hour working on this stuff (80 hours a week probably) because it was my thing. That's an inhumane expectation to force on anyone (and I can't even do it myself anymore now, due to an 11 month old and other real-life things). I took a huge amount of institutional knowledge with me. It takes a lot of time to stuff that much info into someone's head.

I think you're mischaracterizing them as "wanting to knock one out of the park sans help." -- Everyone wants to knock things out of the park, and they're not trying to do it without help. Rather, they're trying to balance what they're capable of (including grappling with all my code sprawl over several years, bringing new developers on board, and doing other for-pay non-QC projects with limited man-hours) with a reasonable set of input for direction. Things you point out are possible, and some are even good ideas. However, I don't believe they're immediately in a position to pull them off at the moment. So there's no point asking you for a list of wants, when they know they'll hit 1 or 2 items on it at best (and then get a huge sprawling thread on the forums, such as this ;). For them to have turned a new version with new features at all is an incredibly good thing - it shows that they've worked with the code some, tackled some problems in it, and now they're more familiar with the code base. I expect even more in the future, provided they have time (Keep in mind that I don't think kineme.net is wildly profitable, so it's not always going to be on the front of everyone's todo list).

Don't take this the wrong way. I almost certainly won't be reading replies to it, so if you'd like to discuss it in more detail, I'd suggest it happen over email (and we can distill the good bits here if you'd like ;).

gtoledo3's picture
Re: Quartz Builder 1.3 second display issue

I'm not going into it deeply since you state you're not going to be reading the reply here.

I strongly disagree with many of your points, especially with the template, the splitters, the mouse, and whether or not structs could have been addressed in Lion 32 bit. Why go point for point in public forum and then say "hey, not going to read a response unless you send it in private"? I love ya Chris, and I understand the knee-jerk reaction of defending some of this stuff - you built the original versions and worked at Kosada, but you've also simultaneously not defended many of the points you're massaging here, elsewhere.

Clarification: When I talk about an alpha blend mode that works with QB, I guess I remember the original issue and solution better - GL TOOLS didn't get pulled if there wasn't a "GL TOOLS" patch, but QC Blend Port was a 4 value, or connected to something. That did and I'm pretty sure, does still exist, if someone uses the old version of GL Tools. Not going to bet on it, but I never had to keep a special version around.

As far as redist of Apple code, and frameworks - actual bundling, vs. linking to one in the OS, I'm dubious, because it will be deployed on OS X. A popular company used to actually bundle the QC.app in their installer, and this was in the Apple App Downloads page for YEARS. I'm also dubious about whether a solution to structs in Lion 32bit actually would require that, even IF not working in QC proper.

cwright's picture
Re: Quartz Builder 1.3 second display issue

So basically, my RSS feed in Mail.app broke, and I haven't bothered to fix them, so I don't get notifications like I used to. That's why I didn't want to commit to replying. I'm going to be away from my personal machine for the coming week, further inconveniencing me. I don't like committing to inconvenient things.

I didn't go point for point (note the lack of quoting you).

I wish we didn't hijack someone else's thread for this discussion. Apologies to OP.

Can you cite the "elsewhere" you're referring to? My reply wasn't about defense (I have no stake in this game), I'm simply explaining the difficulties involved. The complexity involved is an implementation detail that I spent a lot of time hiding from people. As a result, a lot of people don't understand that it's orders of magnitude more easy to say "well, just shim it!" than to actually do it and get it reasonably correct.

I'll hold you to the same standards you set forth in http://kineme.net/forum/DevelopingCompositions/Preparing3dfilesforthe3DO... : how did blend port handling change? it might still be a 4 value - that will still give incorrect results, so I don't see how it's a meaningful metric whether or not the value's there.

Regarding redistribution, it's not a matter of being only on OS X - it's a matter of copyright. Nobody here has the right to redistribute Apple-owned frameworks, period. Whether or not violations of that have been enforced is totally orthogonal. While Apple may or may not enforce, it's reckless to sell a tool that produces products that can cause a user to unwittingly violate international copyrights.

gtoledo3's picture
Re: Quartz Builder 1.3 second display issue

cwright wrote:
So basically, my RSS feed in Mail.app broke, and I haven't bothered to fix them, so I don't get notifications like I used to. That's why I didn't want to commit to replying. I'm going to be away from my personal machine for the coming week, further inconveniencing me. I don't like committing to inconvenient things.

I didn't go point for point (note the lack of quoting you).

I wish we didn't hijack someone else's thread for this discussion. Apologies to OP.

Agree.

The only reason it has gone "there" is because I replied that QB didn't get the same alpha testing this time. Jaymie asked why I assumed that, and I listed why it didn't. That's simply fact. That's not a matter of opinion. There is no valid alternate way of looking at it.

cwright wrote:

Can you cite the "elsewhere" you're referring to?

Yes, in private discussion, re: pulling alphablend into resources. I think it's bad form to go into that more here, but suffice it to say, you did agree with my take, and it took wrangling to convince smokris of it as well (why the arguing? I don't know. It's a feature that was there, and then got broken, thus, it's a bug when it no longer works. I'd think someone would want their suite of products to work together well, without people going "what the heck, this looks totally broken. Wasn't this thing supposed to pull my plugins?")

cwright wrote:

My reply wasn't about defense (I have no stake in this game), I'm simply explaining the difficulties involved. The complexity involved is an implementation detail that I spent a lot of time hiding from people. As a result, a lot of people don't understand that it's orders of magnitude more easy to say "well, just shim it!" than to actually do it and get it reasonably correct.

Sure, people use phrases sometimes and aren't aware of what's involved. Yet, a graph can be analyzed, and a new patch placed in. This could be done with Consumer patches ala macro transmutate, or providers. You guys just thought it was a dumb idea and argued a lot about connections breaking (which they do with macro transmutate anyway). There's no reason why connections would have to break in this scenario at all.

cwright wrote:

I'll hold you to the same standards you set forth in http://kineme.net/forum/DevelopingCompositions/Preparing3dfilesforthe3DO... : how did blend port handling change? it might still be a 4 value - that will still give incorrect results, so I don't see how it's a meaningful metric whether or not the value's there.

I'm not 100% sure I follow your logic, especially in reference to that thread.

When alphablend port was part of GLTools, QB got set in an update so that if a blend value was 3 (sorry, I said 4 earlier), or was connected to a noodle, it would get pulled into resources.

When tons of users, who had NO CLUE what they were doing, and don't do stuff like ... realize that sometimes stuff changes between OS's, complained about the alphablend side effect in QC when SL hit, it was fixed, and extracted into a separate patch, hosing the QB fix. Why I'm repeating this, I do not really know, because you, I, and kineme et. al, know this already (or, I guess Kineme actually didn't know at first. That sounds like a knock, but it is NOT. No one @ kineme was super familiar with using the app on a day in day out, nor building compositions on a day in day out, while working with/writing plugin projects to make them happen. I don't say that as a knock, it's just how it is. I'm not impugning smarts here, but there's much to be said for the accumulation of experience....which was lacking here, in this particular instance.)

cwright wrote:

Regarding redistribution, it's not a matter of being only on OS X - it's a matter of copyright. Nobody here has the right to redistribute Apple-owned frameworks, period. Whether or not violations of that have been enforced is totally orthogonal. While Apple may or may not enforce, it's reckless to sell a tool that produces products that can cause a user to unwittingly violate international copyrights.

Chris, you based much of your career famously violating Apple's Developer agreement, and now you work for them (backwards engineering clause anyone?) I respect your point, yet I find it... curious for you to be the one making it. Yes, that is a bit orthogonal (but not totally!) Not knowing the full impact of the breakage of structure in QC Lion, I can't comment on whether or not structure could have been made to work without redistribution of not "acceptable" code to be redistributing.

"I. Other Restrictions. You may not and you agree not to, or to enable others to, copy (except as expressly permitted by this License), decompile, reverse engineer, disassemble, attempt to derive the source code of, decrypt, modify, or create derivative works of the Developer Software or any services provided by the Developer Software, or any part thereof (except as and only to the extent any foregoing restriction is prohibited by applicable law or to the extent as may be permitted by licensing terms governing use of Open-Sourced Components). You agree to use the Developer Software and the Services (as defined in Section 6 below) in compliance with all applicable laws, including local laws of the country or region in which you reside or in which you download or use the Developer Software and Services."

Doesn't that sorta preclude QB and it's compiler all together? I mean, you know, if reverse engineering was used or anything? cough cough. QB was up in the old Apple DL's page though (yeah, as you say, orthogonal). Classes are also allowed to be redistributed with Dashcode (you will probably say, orthogonal). I would venture to say that snatching a bit of code to get structs working pales in comparison to what QB already is, in it's defiance of guidelines, not only "sell in Apple store" type stuff, but in what it is, and "how" it is.

I get your drift, but it feels like there's a bit of contradiction.

cwright's picture
Re: Quartz Builder 1.3 second display issue

gtoledo3 wrote:
Yes, in private discussion, re: pulling alphablend into resources. I think it's bad form to go into that more here, but suffice it to say, you did agree with my take, and it took wrangling to convince smokris of it as well (why the arguing? I don't know. It's a feature that was there, and then got broken, thus, it's a bug when it no longer works. I'd think someone would want their suite of products to work together well, without people going "what the heck, this looks totally broken. Wasn't this thing supposed to pull my plugins?")

too many things are getting conflated. (I agree on bad form of personal-into-forum bits, thanks :).

So: I believe there's a reasonable solution (smokris agrees, iirc. needs to be implemented, takes time).

Did the feature ever exist? That I doubt (or if it did, it was never mainline). If it never existed, it's not a bug/regression because it never got worse (it simply didn't get better).

AB vs. GLTools doesn't change the fact that QB doesn't import "patchless" plugins. That's a bug in that behavior isn't correct, but again it hasn't regressed. and if it has regressed, that's the "show me the money" bit -- show a build where it pulled in patchless plugins.

gtoledo3 wrote:
Sure, people use phrases sometimes and aren't aware of what's involved. Yet, a graph can be analyzed, and a new patch placed in. This could be done with Consumer patches ala macro transmutate, or providers. You guys just thought it was a dumb idea and argued a lot about connections breaking (which they do with macro transmutate anyway). There's no reason why connections would have to break in this scenario at all.

"you guys" = ? I am not kineme. Neither party thinks it's a dumb idea (as far as I understand it), it's that it's difficult to execute well/reliably (synthesizing connections in an existing graph is tricky, and requires a lot of juggling because of the data structures involved). neither party (again, as far as I understand it) likes shipping broken implementations, especially when graph-manipulation is on the line (breaking existing connections due to a bug is a pretty bad bug).

gtoledo3 wrote:
I'm not 100% sure I follow your logic, especially in reference to that thread.

When alphablend port was part of GLTools, QB got set in an update so that if a blend value was 3 (sorry, I said 4 earlier), or was connected to a noodle, it would get pulled into resources.

My understanding is that that update is apocryphal (I have seen no evidence that it exists - grepping the source archive I have from 2009 doesn't include a reference to GLTools, so there's no possible way QB could add the plugin for you based on the port value). This is the "show me the money" bit again: This build didn't exist - if it did, please present it.

Now, if such a build exists, then it would stand to reason that it should be updated. So once more, please present the build. Without the build, there's no evidence it was ever implemented at all (and thus it cannot be "updated" to do the right thing).

I present as further evidence that this build is mythological: I can make a composition with exactly 1 patch (billboard). I can change the billboard's blending to Alpha). I can then save the composition, and load it into QB. I can then inspect the resources. If it was "broken", it would mistakenly add GLTools to the plugin list (because it hasn't been updated, as you've been asserting). However, it doesn't. It shows no plugins. Therefore, I can conclude that it's not in need of an update, it's in need of an initial implementation. Those are two wildly different things.

gtoledo3 wrote:
Chris, you based much of your career famously violating Apple's Developer agreement, and now you work for them (backwards engineering clause anyone?) I respect your point, yet I find it... curious for you to be the one making it.

You're conflating 2 distinct ideas. One of copyright (the ownership of a work, with restrictions on redistribution of those works), and one of EULA (the "Develoepr Agreement"). Distributing binary code (what bundling the framework would be) that is owned by Apple is a crime (in the united states and many other countries). Is it a violation of copyright unless Apple grants distribution rights. It is exactly identical to me downloading your compositions, and then distributing them in my own things without your consent (I'm sure I can dig up a thread around here where you rally against that practice). Violating an EULA, at least in the US, is not a crime. The Senate Judiciary Committee recently approved a bill which amends the Computer Fraud and Abuse Act to clarify that ToS/EULA violations are not criminal (https://www.eff.org/deeplinks/2011/09/senate-committee-agrees-violating-...). I participated in the latter (reverse engineering and all that). I have not violated Apple copyrights by redistributing their works.

You claim these ideas are not totally orthogonal, but in fact they are. Further, it's a logical fallacy to state that, because one infraction has taken place (eula), that others are now free to be performed (copyright). That's like saying "Well, because I jaywalked this morning (an infraction or misdemeanor, depending on jurisdiction), I might as well kill somebody (a felony)."

gtoledo3's picture
Re: Quartz Builder 1.3 second display issue

Yep, I was thinking of the round of fixing that happened with alpha sliders on color wells and underscores getting hidden not working (just was looking through emails). I also see some discussion about the resource functionality, and that being related.

Correct, I was off of my butt on that one, and fall on my own sword. I see that it was resolved by manually loading, or placing a macro environment on the editor. (I was never really happy with that, because, again, it sorta doesn't hold up to the suggestion that QB loads the patches you're using. I've also not been happy with the sheer amount of inquiries and time I've spent explaining this to people, who ask me, instead of kineme, for some reason. I'm guessing they look and go, "well, kineme didn't actually get it right, let me ask this guy". Harsh? Not trying to be, but it happens.)

On the patch swap - kcore already ships w/ transmutate. I'm suggesting that this can simply be done with any kind of patch, and if ports match up, there's no breaking of the graph (err, like does happen with transmutate!).

If you backwards engineer something, and distribute the resulting code, you are distributing code that isn't yours. So, using the analogy, if my qtz has been reduced to assembly or something (don't kill me with my semantics), and I use class dump to then backwards engineer it, and then distribute swarths of programming based on it, it's actually violating TWO principles. Backwards engineering & distribution of copyrighted materials.

The mention of bundling the framework is potentially hacky and egregious, but I also suggest that this may not be the only solution. Maybe it is. I suggest the framework bundle, or other "grab working code to make a patch" route, even though I'm pretty famously a defender intellectual property, because I think this rates about a zilch on Apple's radar (eh, yeah, I'm wresting with justification on that. It shouldn't be redistributed). I do know it (structure hijinx) was a surprise that came up after release of the last QB.

Remember: QB already grabs things that are not redistributable Apple sample code. ImageDiffer, and friends, are not redistributable sample code. The fact that QB bundles them into resources is a hack, and already a violation.

Let's wrap this one. Further discussion should happen in private.

Swiftlikeninja's picture
Re: Quartz Builder 1.3 second display issue

Wow, I didnt intend to unleash this level of wrath onto the community!

On the plus side, full screen appears to be working, at leaste with a second display. I will get around to testing it with upwards of 8 screens soon.

Thanks @jstrecker