On Wed, Jun 1, 2011 at 13:05, thron7 <[email protected]> wrote:
> I'll try to answer all 3 mails in one...
>
Thanks, Thomas.
>
> On 06/01/2011 05:12 PM, Derrell Lipman wrote:> main : function()
> > console.log("Testing for qx.debug");
>
> 'console' is browser API, not qooxdoo.
>
Of course. I wanted messages that would appear even when I expected no
widget.debug messages to appear.
> > In fact, pressing CTRL-D brings up the appender window onscreen too.
>
> Are you talking about the qooxdoo console (usually with F7)?!
>
Yes, but F7 doesn't work for me (never has) but CTRL-D does. The code in
Keyboard.js allows for both key combinations.
> > This definitely seems like a bug. These appenders should exist in
> > the build at all.
>
> This should probably read "should _not_ exist", right?!
>
Yes.
>
> Well, as you mention them in code that doesn't get optimized away, they
> are include. Ok?!
>
I understand what was happening, and I've modified all of the code so that
I'm no longer supporting the older versions. I'm not going to support
multiple versions of the same code, so if I need to choose one, I'll support
only the newer one.
>
> > Ok, the problem is that the test for qx.core.Variant is bringing it
> > in even though that's not defined.
>
> I don't get it. What does qx.core.Variant bring in? qx.core.Variant is
> defined as soon as you mention it (s.above).
>
Since qx.core.Variant.isSet() was not removing the references to the
appenders, the appenders were being included. That's what I meant. Makes
perfect sense once one figures out what's going on.
> > What is the working method of supporting both qx.core.Variant and
> > qx.core.Envrionment in contribs?
>
> If you mean how to support them *at the same time*, you can't. There
> were versions of qooxdoo that hadn't qx.core.Environment, and there will
> be versions that won't have qx.core.Variant.
>
> If you mean to have a code base that can be used under both versions,
> you could use variants, you can't either. Theoretically you could have
> switches in your code. Say you are working with qooxdoo 1.4. You could
> add code like
>
> if (qx.core.Environment.get("qx.version") !== "1.5") {
> // add pre-qx.core.Environment stuff
> if (qx.core.Variant.isSet("qx.debug", "on") { ... }
> else {
> // qx.core.Environment stuff
> if (qx.core.Environment.get("qx.debug")) { ... }
> }
>
This wouldn't work. In older versions, qx.core.Environment wouldn't exist,
so the above code would crash. That's exactly what I was trying to work
around. No longer. It's not worth it.
> Best is, you create different versions of your contrib, one that works
> with qx.core.Variant, the other working with qx.core.Environment. Much
> cleaner. And the contrib demobrowser will thank you :).
>
Nope. Too much work for me to maintain them. One version. If people want to
use it, they'll keep up to date, or they'll use the older version of the
contrib.
Now as it turns out, the contribs work absolutely fine with the older
versions of qooxdoo. The only things that don't work are the demos, because
of this issue.
> > How do I get code to be excluded if
> > NEITHER qx.core.Variant.isSet() nor qx.core.Environment.get() is true?
>
> It is the wrong question. You could crumsily test for either of them, like
> if (qx && qx["core"] && qx["core"]["Variant"]) ...
>
> or something, but as I said above as soon as you mention the class, it
> gets included (if it is available), and if you don't mention the class
> the code doesn't get optimized. You cannot sniff the classes that are
> the implementation tools of the variant optimization.
>
> I hope this answers most of your questions.
>
Yeah, I had already answered all of these for myself in the interim, except
whether you'd provided some way to test for both the old and new way, and
exclude code if qx.debug was "on" via either the old Variant method or the
new Environment method.
I hadn't realized until today what a significant change this is. I think it
was a mistake to do such a quick transition from Variant to Environment. For
contrib maintainers, it means choosing between supporting multiple versions,
or, as I did, choosing to support only the new version, with really no
reason not to support the older versions too, except for excluding debug
code in a build. That's really pretty silly, I think. Those are my thoughts.
Cheers,
Derrell
------------------------------------------------------------------------------
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
