After further analysis, I discovered that it is in fact the "include" key that is recommended at: http://qooxdoo.org/documentation/0.8/migration_guide_from_07#manual_work which causes my classes to not be included. And since, trunk includes that ""fix"" by default, it's logical that the sample generated by create-application doesn't work either.
The problem is that if I remove those includes, I get: [Exception... "'Error: The meta theme to use is not available: qx.legacy.theme.ClassicRoyale' when calling method: [nsIDOMEventListener::handleEvent]" nsresult: "0x8057001c (NS_ERROR_XPC_JS_THREW_JS_OBJECT)" location: "<unknown>" data: no] which is probably why the "include" thing was added in the first place, I guess. Could you please fix this bug ASAP as it renders any migration through "legacy" widgets impossible! On Wed, Sep 24, 2008 at 9:58 AM, Gaetan de Menten <[EMAIL PROTECTED]> wrote: > On Tue, Sep 23, 2008 at 7:22 PM, thron7 <[EMAIL PROTECTED]> wrote: >> >>> I've followed the migration guide at: >>> http://qooxdoo.org/documentation/0.8/migration_guide_from_07 >>> >>> Up to checkpoint 1, it works fine with 0.8 (but *not* with trunk -- see >>> below), >>> >> >> Checkpoint 1 just assures that the skeleton application can be built >> after the copying. So this is very basic. > > I know... Yet it fails with yesterday's trunk... > >>> - then the migration job/script seem to execute fine. >> >> This is what I don't understand. There is not much use in migrating the >> skeleton app. The important point is that you copy the app you want to >> migrate into the skeleton structure, overwriting the skeleton's >> ./source/* subtree. (The feedreader is just an example on the wiki page). > > Of course I did copy my app... Migrating the skeleton doesn't interest > me much either... > >>> - I did the manual edit of config.json as recommended >> >> Not sure what you modified there. > > http://qooxdoo.org/documentation/0.8/migration_guide_from_07#manual_work > >> Anyway, the migration should work with >> the config.json just as it is. > >> *Now* you would run the migration ('generate.py migration'). There >> should be a log file for the migration (and some console output) that >> inform you which files have been modified. Do you see your application >> files being modified? > > Yes, my files are modified. > >>> - ./generate source again, it seems to work fine >>> >>> Now when I try to access the actual application (checkpoint 2), it >>> requests a bunch of js files from the server (as it should) but then >>> the page stays blank and the main() function of my app never gets >>> called. Has anybody got any clue as to what might be causing this? >> >> This is strange. For one thing, why would it request files from the >> server? Don't you open the app locally? > > The server is actually localhost... But if by "locally" you mean > opening the local index.html file directly in the browser, then no, I > can't do that since my app requires some content that is generated by > the server. > >> The entry point to your >> application is the <namespace>.Application class. Is this correct for >> your app? > > Yes, I think it is. > >> If not the correct class has to be configured in the >> config.json ("settings" -> qx.application), but you can also do this in >> the index.html. >> >> I'd like to ask you to look into these issues and provide a bit of >> clarification, before delving deeper into the rest of your mail. > > After I sent my email yesterday, I found out that the problem was in > fact due to my classes not being included, so I changed config.json to > read: > > "common" : > { > "include" : ["qx.legacy.theme.ClassicRoyale", "xyz.*"], > ... > > and now I got one step further: I see my app menu and some errors... > Hurray... But this is probably not the way to go as there are > apparently still some issues with dependencies, as I get: > > qx.locale.Manager is undefined: > this.__locale = qx.locale.Manager.getInstance().getLocale(); > > Do you have any idea why my classes are not included automatically? > >>> >>> As a side note, by default, there is no logging whatsoever. How do you >>> enable logging in 0.8? >>> >>> More specifically, I'm looking for the equivalent of: >>> APPLICATION_SOURCE_LOG_LEVEL = debug >>> APPLICATION_BUILD_LOG_LEVEL = error >>> >>> I've skimmed through all the generator documentation I could find but >>> didn't find *any* mention of logging. Is it something that cannot be >>> configured at the Makefile level anymore? >>> Couldn't you guys write a migration script for the Makefile? -- Gaëtan de Menten http://openhex.org ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
