thx for all this. The new boss is being annoying and asking me to do
work, could be a week or three before I can return to this.
kt
ps. I have been able to toggle between classic and modern by mucking
with setTheme, but maybe I just got lucky. kt
On 10/19/2010 11:32 AM, thron7 wrote:
>
>
>>> What does that mean? Normal qooxdoo app loading, or do you use parts, or
>>> what?
>>
>> Normal qooxdoo application loading. The start-up ends up with an XHR
>> request "begin". The server responds with a ton of JS that gets evaled
>> and builds the first "page". All events get XHRed back to the server,
>> each returning more JS to morph the DOM.
>
> This begs the question how the server knows what to return. Does it
> implement its own dependency tracking? How does it relate to what the
> 'generate.py build' job spits out?
>
>
>>>> I have it working to use qx.theme.Modern by first including a simple
>>>> reference to the class
>>>
>>> To which class, qx.theme.Modern?!
>>
>> Yes. I am setting the theme dynamically.
>
> But the tag line, since a couple of qooxdoo releases, is "themes cannot
> be changed dynamically". So, I don't know how it is implemented but my
> best understanding is that you just have to set the setting "qx.theme"
> to the meta theme class, and that's it. I'm not sure the setTheme() call
> does anything effectful, which probably didn't matter for
> qx.theme.Modern as it is the default qx.theme anyway. - Try commenting
> out the setTheme call and see if it still works.
>
>>
>>>
>>>> in Application.js, which I have end with an XHR
>>>> on a URL "/begin"
>>>
>>> Is this significant for the problem?
>>
>> Do you love requests for information that hold back what the asker
>> thinks/hopes does not matter? Not me!
>
> Just trying to figure it out...
>
>>> The interesting question is, is the Modern theme still drawn in as well?
>>
>> Not sure what you mean. Nothing happens, I get the qx.Class error.
>
> Sure, in the running app. But what about the generated .js files?!
>
>>> Do you want to list all classes you use in your Application.js<rofl>?!
>>
>> teamalgebra.com
>>
>>> That's a funny way to code.
>>
>> This is a funny way to offer technical help.
>
> Now, now, you and your teamalgebra have all of my sympathy. But there
> are really, um, more canonical ways to inject dependencies than listing
> class names in the app code. - Still I don't get how this all fits
> together, as I don't have a picture how the generate.py build output and
> your server delivering code to the client relate to each other. If you
> e.g. were using standard qooxdoo parts I would be able make some
> assumptions about their properties and what gets sent from the server when.
>
>> Apparently you did not understand what John McCarthy did back in 1956
>> when he realized code should be data.
>
> :-) No, indeed, as I wasn't born at that time ;). (C'mon, Kenny, this
> isn't c.l.js).
>
>> teamalgebra.com is a Common Lisp application including an Algebra editor
>> and Algebra expert engine running on the server. Somehow the server
>> application seamlesly includes a GUI layer that runs on the interweb.
>> Still laughing?
>
> Never laughed about that. Some other projects use qooxdoo as the pure
> rendering layer for a server-driven app. But that raises a lot of
> issues, as that of dependency tracking on the server, I'm not familiar
> with, and can be done in various different ways.
>
>> Yes, I did that. That is what I was asking. I did both the bar
>> darktheme.DarkTheme in Application.js and set the QXTHEME JSON value
>> (not sure why you say macro)
>
> That's just lingo, to emphasis their use in the config system (think of
> m4 rather than Lisp :).
>
>> to "darktheme.Theme".
>
> Right, so the points I wanted to get at were:
>
> - are the darktheme classes included in the build? - you can check that
> by looking at the generated .js files (just grep for their class names);
> what you write slightly suggests they're in.
>
> - are the theme classes delivered to the client? - I have no idea, as I
> don't know how your server-side code packager does and how it assembles
> the code packages it sends back to the client; in the worst case, you
> have to inspect the files *in the browser* in some debugging console, to
> check if the theme classes arrive there.
>
> - in the browser console, check the "qx.theme" setting
>
> qx.core.Setting.get("qx.theme")
>
> and its availability
>
> qx.Theme.getByName("darktheme.DarkTheme")
>
> This is all focused on theme handling, so actually doesn't answer the
> question why qx.Class would be undefined. Again, you have to inspect the
> downloaded .js files. I presume your initial Application.js is not run,
> so the issue must be in the very first package. How is this package
> created? What is actually in it? Which qooxdoo classes?
>
> T.
>
> ------------------------------------------------------------------------------
> Download new Adobe(R) Flash(R) Builder(TM) 4
> The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly
> Flex(R) Builder(TM)) enable the development of rich applications that run
> across multiple browsers and platforms. Download your free trials today!
> http://p.sf.net/sfu/adobe-dev2dev
> _______________________________________________
> qooxdoo-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
--
http://www.stuckonalgebra.com
"The best Algebra tutorial program I have seen... in a class by itself."
Macworld
------------------------------------------------------------------------------
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
