by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Sep 18 20:58
    lucapivato commented #10037
  • Sep 18 07:24
    oetiker labeled #10037
  • Sep 18 07:24
    oetiker commented #10037
  • Sep 18 07:22
    oetiker edited #10037
  • Sep 16 16:15
    lucapivato labeled #10037
  • Sep 16 16:15
    lucapivato opened #10037
  • Sep 11 08:35

    github-actions[bot] on gh-pages

    deploy: 514690aa24bb25ae0295c8d… (compare)

  • Sep 11 08:33

    dependabot[bot] on npm_and_yarn

    (compare)

  • Sep 11 08:33

    hkollmann on master

    Bump node-fetch from 2.6.0 to 2… (compare)

  • Sep 11 08:33
    hkollmann closed #759
  • Sep 10 23:19
    gasoved starred qooxdoo/qooxdoo
  • Sep 10 20:11
    dependabot[bot] labeled #759
  • Sep 10 20:11
    dependabot[bot] review_requested #759
  • Sep 10 20:11
    dependabot[bot] review_requested #759
  • Sep 10 20:11
    dependabot[bot] review_requested #759
  • Sep 10 20:11
    dependabot[bot] opened #759
  • Sep 10 20:11

    dependabot[bot] on npm_and_yarn

    Bump node-fetch from 2.6.0 to 2… (compare)

  • Sep 07 13:04
    cboulanger assigned #10036
  • Sep 07 13:04
    cboulanger opened #10036
  • Sep 07 12:36
    zaucker edited #10035
hQx1tSXbclz4sei5
@hQx1tSXbclz4sei5

I also have a few questions...
1) I have divided the program into modules and when I run the necessary part, I can get a string like:

"prj.module.Name" // from this.classname.

How to initialize the object correctly, as it is usually done, but from the resulting string above:

new prj.module.Name();

Perhaps there are solutions provided?

2) Question follows in the continuation to the question above. since modules are launched when they are called directly, and some may not be launched at all, since the rights of users are limited. I connect classes this way:

/*
 * @require(prj.module.Name1)
 *    ...
 * @require(prj.module.Name20)
 *  ...
 */

Is there any way to make the project include all classes from "prj.module", as well as folders and nested classes and folders automatically, without manually prescribing all 20+ @require?

Christian Boulanger
@cboulanger

@hQx1tSXbclz4sei5

How to initialize the object correctly, as it is usually done, but from the resulting string above:

let Clazz = qx.Class.getByName("prj.module.Name");
let module = new Clazz();
hQx1tSXbclz4sei5
@hQx1tSXbclz4sei5
@cboulanger Thanks for the quick response too!
Christian Boulanger
@cboulanger
@hQx1tSXbclz4sei5 I think it is possible to do @require(prj.module.*) now, but since the page on this seems to be missing in the new docs, we'll have to ask @johnspackman
hQx1tSXbclz4sei5
@hQx1tSXbclz4sei5

@cboulanger

@require(prj.module.*)

Not. It didn't work. ("@qooxdoo/compiler" : "^1.0.0-beta.20200602-1225")

Henner Kollmann
@hkollmann
You can add prj.module.* into the include section in compile.json
hQx1tSXbclz4sei5
@hQx1tSXbclz4sei5
@hkollmann It works! Thank you! But, it remains not obvious to those who are not familiar with qx and may cause questions to the class, why it works and how the application sees the class? It would be more convenient to add this to @require() or maybe something like:
qx.Class.require([
    "prj.module.*",
    "prj.blahblah.*",
    ...
]);
qx.Class.define("prj.core.Start", 
{
    ...
});
Christian Boulanger
@cboulanger
@hQx1tSXbclz4sei5 I agree this needs to be better documented - it is not obvious where to look for it in the documentation. What you are asking for is dynamic dependency resolution, which is not how qooxdoo works. Qooxdoo apps need to be compiled, which adds a bit of overhead but since compiling is so fast now and we have continuous compilation, that's hardly an issue any more. In return, you get highly optimized code which can be tuned in all kinds of ways. So as @hkollmann says, using compile.json's applications[x].include array is the way to go for the moment. If you want, you can open an enhancement issue in the qooxdoo-compiler repo to ask for the support of @require(foo.*) but I don't know if that's technically possible with the current dependency resolution algorithm.
Oleg Philippov
@ofilippov
Good afternoon.
Let's say we have defined class C which extends class S which implements interface I. If we have a method "m" in interface I which is implemented in class S and overwritten in class C then we can have a construction in C.m: this.base(argumnets), and in compiled code it is going to be C.prototype.m.base();
At the same time in debug mode we have methods from interface wrapped (see qx.Interface - __wrapInterfaceMember). And these wrapped methods don't have property "base" and our debug code doesn't work.
Can we call it a bug?
Thanks.
Oleg Philippov
@ofilippov

One more question.
https://github.com/qooxdoo/qooxdoo/blame/master/framework/source/class/qx/ui/tree/VirtualTree.js
Here we have property "showTopLevelOpenCloseIcons" - false by default.
And method

isShowTopLevelOpenCloseIcons : function() {
      return true;
    }

It looks very wrong.

Henner Kollmann
@hkollmann
@ofilippov could you create an PR for the second issue please?
Derrell Lipman
@derrell
@oetiker a month or so ago, you PRed some code, somewhere, that allowed, IIRC, form field validation to occur after there had been a match, or upon focusout of the form field, or some such thing, so that each field could be validated, but you didn't get the validation-failed message when you first started typing into the field. Am I remembering correctly? What class and property was it that controls that?
Oleg Philippov
@ofilippov
@hkollmann here it is qooxdoo/qooxdoo#10019
@derrell I can remove the whole method, if you think that it would be better :)
Oleg Philippov
@ofilippov
I just don't know why it is there in a first place
Derrell Lipman
@derrell
@ofilippov Please give it a try. I think you'll find that the method still exists, due to the automatic creation.
Do you understand my explanation?
Oleg Philippov
@ofilippov
@derrell yeah, I know it will be there, just not sure how interface will process it.
Derrell Lipman
@derrell
Good point. I guess you'll find out :-)
Oleg Philippov
@ofilippov
:D
let me try
Derrell Lipman
@derrell
Thanks
Tobias Oetiker
@oetiker
@derrell this here qooxdoo/qooxdoo@91ab5fb
Derrell Lipman
@derrell
@oetiker. That's exactly what I was looking for. Now I just need to figure out how to take advantage of it with this Dialog package... Thanks!
Oleg Philippov
@ofilippov

Short example about my first problem:

qx.Interface.define("test.IItem",
{
  members :
  {
    method : function() {}
  }
}

qx.Class.define("test.AbstractItem",
{
  extend : qx.core.Object,
  type : "abstract",
  members : 
  {
    method : function() {
      console.log("AbstractItem");
    }
  }
}

qx.Class.define("test.Item",
{
  extend : test.AbstractItem,
  implement : [test.IItem],
  members : 
  {
    method : function() {
      this.base(arguments);
      console.log("Item");
    }
  }
}

In class qx.Interface we have method __checkMembers with code:

object[key] = this.__wrapInterfaceMember(
  iface, object[key], key, members[key]
);
__wrapInterfaceMember : qx.core.Environment.select("qx.debug",
{
  "true": function(iface, origFunction, functionName, preCondition)
  {
    function wrappedFunction()
    {
      // call precondition
      preCondition.apply(this, arguments);

      // call original function
      return origFunction.apply(this, arguments);
    }

    origFunction.wrapper = wrappedFunction;
    return wrappedFunction;
  },

  "default" : function(iface, origFunction, functionName, preCondition) {}
}),

So, our test.Item.prototype.method is going to be replaced with wrapper and this wrapper doesn't have base property.

I think we can add here:
wrappedFunction.base = origFunction.base;
Derrell Lipman
@derrell
That's a really invasive change. How about instead, call this.base(arguments) ; before console.log("AbstractItem"); ?
Oleg Philippov
@ofilippov
But in any case test.Item.prototype.method.base is undefined here
cause test.Item.prototype.method is a wrapper
Derrell Lipman
@derrell
But aren't you saying that the wrapper has been broken for 15 years and it's never come up before? Certainly possible, but seems there's something else going on that's missing...???
Oleg Philippov
@ofilippov
well, it works fine in qooxdoo 5.0.2 at least :) but I'm not sure that this.base(arguments) was compiled to test.Item.prototype.method.base() before
Derrell Lipman
@derrell
What is the set of circumstances in which this problem would occur? Not likely whenever an interface is used, but that seems a requirement to cause this. What are the other requirements to cause it?
Ah, a possible change. Yes that's a potential cause. But still, interfaces are used throughout the core code, so what else is required to cause this?
@johnspackman Is this.base(arguments) implemented differently with the compiler than it was with the generator?
@ofilippov are you able to try a small test with 6.0 qooxdoo code but compiled with the generator instead of the compiler? The generator is deprecated but still included with 6.0.
I'm just really concerned about a change as invasive as something in the wrapper functions.
Oleg Philippov
@ofilippov
as far as I see, in qx 5.x function base from qx.core.Object is used in debug
Derrell Lipman
@derrell
@ofilippov Let's see what @johnspackman says. He's the expert in that area.
John Spackman
@johnspackman
@ofilippov @derrell the change between generator and compiler is that the generator would rely on the method base in the code - so this uses the Javascript runtime to figure out what that should be. However, the compiler has to predict what the method would be, and replaces this.base(arguments, …) with an explicit call, eg test.AbstractItem.method.call(this, …). So, the upshot is that it is possible that the compiler has not properly figured out the correct method to explicitly call. Please can you create an issue with a reproducable test case and I will have a look. BTW the reason that the compiler must figure it out is because the compiler transpiled to ES6 which requires strict mode - and in strict mode, it is illegal to use arguments to figure out the function being called, and therefore the default implementation of base in qx.Object cannot and will not execute. The fix is to edit the code to transpile this.base() as the explicit function call.
Derrell Lipman
@derrell
Thanks @johnspackman
tobscada
@tobscada
Hi
I'm try to use "qx create helloworld -type mobile -I " command to create new mobile app but it messaged error to me like ' unknow argument : y, p, e' how could i would do?
Until now I still not touching the new Qooxdoo Mobile App features with no use of Python command.
tobscada
@tobscada
Please be suggested me.
Henner Kollmann
@hkollmann
you have to use --type or just -t
Derrell Lipman
@derrell
G'morning, all. See my comment on qooxdoo/qooxdoo#9979. A property added to AbstractForm in May is not showing up in the API viewer for some reason. Pulling master, it does appear that the code is there. I don't see anything inherently wrong with the property definition. I suspect some problem with the API viewer...
(or regeneration of API docs)
Derrell Lipman
@derrell
Huh... It's in master, but not in the version of qooxdoo that comes with the compiler... but the compiler npm version is really old! npm install @qooxdoo/compiler; npx qx --version yields 1.0.0-beta.20200613-2032... unless there's a more propery way to upgrade the compiler and its dependencies?
Has nothing to do with upgrade. I removed node_modules and reinstalled it, and end up with the same ancient version...
Derrell Lipman
@derrell
@hkollmann Maybe this is related to the dependency work you're actively involved in?