Hi!
I get the following error in Firebug running demobrowser locally after
compilation:
TypeError: tmap.sort is not a function
tmap.sort(topsort);
TreeDat...1579504 (line 126, col 6)
it seems as if the data structure can not be handled that way with adding a
sort on it.
Additionally, I get:
Thanks Daniel,
It was what I supposed. Now flawless...
Stefan
> Hi Stefan,
>
> yes, if you're loading the demobrowser from the file system, the browser
> will restrict access to some external files which leads to these errors.
> If you don't already have a web server running, you can use
>
> pyt
I have a few questions regarding grunt for qooxdoo:
1. When create-application.py is run the directory npm_modules is created in
every project's root directory. This is a lot of clotting.
Would it be possible to search the tree for an already existing pm_modules
directory and then ask if a local
further info:
1. if I install grunt like this:
- npm install in the javascript directory -> does not work as it can not find
dependencies
- if I:
a) copy proj_A node_modules to javascript
or
b) make a npm install in a new project directory and then copy the
node_modules to javascript di
Hi Richard,
You said:
>2) This should work if you need the disk space. Just
>copy the node_modules dir one directory up.
this does print out:
Loading "source.js" tasks...ERROR
>> Error: Cannot find module 'path-is-inside'
Loading "build.js" tasks...ERROR
>> Error: Cannot find module 'qx-resourc
Hej C!
> If this is not a priority of the qooxdoo devs, maybe we should move ahead and
> agree on a standard format to publish contribs as npm modules? That would be
> my personal favorite. Technically, this is very easy, since one can install
> them using npm and then in config.json point to the
ntil now
> which brings me to a good point Petr mentioned in a post:
>
> The problem I see is that qooxdoo tries to be for everything, which is simply
> impossible to achieve for the current dev-team.
> This is one of the main problems we currently face. The whole code base grew
> ov
Is there any reason why the type checking and parameter counting of Interfaces
are heterogeneous?
In some classes
arguments.length == 1
and others
this.assertArgumentsCount(arguments, 1, 1);
are used.
Furthermore, in some
no type checking when incoming parameters of functions/methods
in ot
I will gladly do!
Stefan
> Hi Stefan,
>
> You're right. This framework is growing over the last years with help of many
> developers
> with different paradigms and "styles" of programming.
>
> But with your help and the help of the community we can reach the goal to
> improve these interfaces
We have sent a pull request to the qooxdoo.
As WebSockets have not been implemented the qooxdoo way with basic, fallback,
reconnection, pool, cache, data binding etc, we decided to start it.
Any suggestions on it would be appreciated.
Stefan
Hi Martin,
It is easy to keep it as a contribution if that is what you want.
We chose an enhancement bug as Script/Xhr/Jsonp communication are core
functionality and we believe websocket should be too.
We also used the qx.io namespace of the same reason.
We believed it might help you
...but
Hi Fritz!
> I also understand the argument about core functionality. But putting it
> there only helps if 1&1 has the necessary ressources to maintain it (or at
> least to make sure updates/fixes are checked and integrated in a timely
> manner).
It is so true and therefore maybe 1&1 should look f
Hi,
This is a question you will be criticized for if answered.
> does anybody know the approximate number of active users of qooxdoo?
I can not see more than 20-30 active users and another 20 sporadic users.
Considering how powerful the framework is, it is a very low number!
Possible reason to
He asked for the number of active users!
Stefan
> I don't agree with dev, you cannot give a number because much users are not
> active.
>
>
>
>
> --
> View this message in context:
> http://qooxdoo.678.n2.nabble.com/Qooxdoo-users-tp7586388p7586390.html
>
just to clarify what I meant...
> I think
>
> 1 is wrong. All open sourced.
It is indeed true opensource, which is fantastic and very generous.
What I meant was joint development is NOT open, though it might be changing in
the future...
> 2 Main issue is the requirement to have backend support
Hi,
> Right. My question was how many people use the framework. Not how many
> develop it.
There is no registration function for the people using it, so the figure is
unknown.
Number of downloads does not give it.
Total number of names since the start in this list does not give it.
The closest
Martin!
It is true that users can take initiative to promote the framework, though it
is limited as the user community has been limited by the closeness of the core
team. I can see some places that users of the community really speak well about
qooxdoo. So they do... But I do see, but too littl
and be put off; it seems that the only person
> from the core devs who posts on here regularly is you, and often only in
> response to specific issues. I very much appreciate your attention, but its
> clear that there is a lot going on in the dev team and we see almost none of
> it.
gt;>> * Will it be easier to mix with other JS?
>>>
>>> We are happy with our agile approach and the intermediate results
>>> while addressing specific challenges of the website-oriented
>>> projects. Thus we like to share this good news, well-aware that m
-
You, community, is debating...
Let me make it constructive!
Some of you have too high expectations, and we are surprised that you do not
understand.
You, in the community, are not aware of how to use or don't use the fundamental
means of the project.
You need to recap all this to get a comp
Congratulations John!
This is the major step taken the last 18 months!!! (cause nothing much happens
with qooxdoo anymore while ExtJS and other frameworks develop quite fast)
You have proven it come be done in a very delicate way.
You give the core team a huge challenge...the question is if they
Hi,
> But I’d be interested to collaborate on an official community fork; there may
> not be a huge explosion of development activity ;) but it would give us (the
> community) the opportunity to take the project forward, merging in changes by
> the core 1&1 team.
>
> What do you/anyone think?
Again so mysterious...
No statements...?
What is going on?
I would like to hear what 1&1 will do now? Are you going to release it to the
community and participate or what???
The answers on the above questions must be guiding us what direction to
choose...a community fork or not!
Stefan
> Hi Di
John,
It works very well. No errors when we tested the pull in our test bench.
Well done!
You have done more than a whole team in a year, in a very short time...
Bigger challenge...
We will put it in pre-production testing now in a smaller subproject.
You have really moved qx forward!!!
Stefan
Dear 1&1,
This is tremendous news. They should have come at least two years ago cause now
the project has lost almost all momentum.
Hopefully it can be repaired by a new community which grows more than it is now
as most already have left.
For 1&1:
Thanks 1&1 for the contribution of code to the
Dimitri,
I think it is a good idea.
We have developed language support for different "direction" languages...not
only LTR instead including RTL, TB, BT, MTR etc. It also includes different
calendars etc...
It might be something we could include in that package and then make a pull
request on bo
t;
> *package.json:*
>
> {
> "name": "project",
> "version": "0.1.0",
> "repository": {},
> "devDependencies": {
> "grunt": "~0.4.2",
> "grunt-http-server": "^1.13.0
; now,
>> > I just edited them as below to make the webserver work:
>> >
>> >
>> > *package.json:*
>> >
>> > {
>> > "name": "project",
>> > "version": "0.1.0",
>
rsion": "0.1.0",
>> "repository": {},
>> "devDependencies": {
>> "grunt": "~0.4.2",
>> "grunt-http-server": "^1.13.0"
>> }
>> "license": "Apache-2.0"
>&
John,
We really like your approach of the qxcompiler.
I think it is very important to keep it clean and clear-cut as a tool and not
complicate it now. There might be many wishes to do this and that. It is good
if not moved too fast before knowing what is best for the subproject.
Your ideas behi
: "project",
>> > "version": "0.1.0",
>> > "repository": {},
>> > "devDependencies": {
>> > "grunt": "~0.4.2",
>> > "grunt-http-server": "^1.13.0"
>> &
Thomas,
> I could see Grunt being a command-line frontend for the jobs, with
> QxCompiler remaining a pure API-based library which is included as a
> dependency and utilized from Grunt files.
I agree completely with you in this! Don't invent the wheel again!
> Even if you feel the code in qooxdo
John,
> Thomas, that’s interesting about the grunt development in next, I had no idea
> it had gone so far.
>
> Stefan, I’ve been thinking about not reinventing the wheel, esp. in light of
> Thomas’ comments, and my thought is that QxCompiler should be able to produce
> an application from sour
Hi Defero,
You need to check the following for dynamic loading:
1. if the part has already been loaded (version, build, date etc)
- different versions of the same part might be loadable at the same time
- different language parts
- etc
2. if there are cross referencing
3. circle referencing
4.
After thinking back and forth we have tried to find out about how to make the
UI components independent of the core of the framework.
It would be fantastic if it would be possible to uncouple dependencies other
than the core ones.
Imagine to have a UI component library, which is not decided by
Derrell,
> qooxdoo apps already include only those GUI components that are actively
> used by the user's app. Yes, they're included in the qooxdoo source code,
> but are otherwise unused.
Putting them in a separate library fully accessible at genertion might increase
interest of community to add
SQ,
The idea is good.
What about presenting a compatibility table too?
Then the question is what browsers and their versions should be compatible else
there will be a code overload?
Any impact on speed in any dimension?
Do you have a full testing version?
Do you have any test cases with timers et
SQ,
> Excellent thoughts Stefan!
>
> My quick thoughts on your questions (please point out holes in my logic
> where you see them):
>
> Take the list of images in this file
> (https://github.com/sqville/sqv/blob/master/source/class/sqv/theme/clean/Image.js)
> as the official list of images that I
one important thing here...
the benefit of local rendering is support of accessibility - making your GUI
usable by people with disabilities
This is a very important improvement!
Many users, even those not visually impaired, benefit from magnification of
text and graphics. However, without magn
Hi John,
> Hi Stefan
>
> I hadn't seen this when I replied earlier, but reading it now I think that
> this touches on the discussions ages ago about how to integrate
> contributions into builds.
>
> If bringing in outside contributions could be simplified, then the
> location and contro
Hi John,
I have seen that you have started integrating your changes into qooxdoo master
branch.
Is it ready to drop your fork of qooxoo now? i.e. use the original...
Stefan
--
Transform Data into Opportunity.
Accelerate
41 matches
Mail list logo
