subject:"Re\: \[qooxdoo\-devel\] \(off topic\?\) Qooxdoo's ecossystem question"

Re: [qooxdoo-devel] (off topic?) Qooxdoo's ecossystem question

2010-09-15 Thread flj

>>Wait, you say at your business 21 developers work 100% of their time on 
>>such a qooxdoo app, and you call it a "simple bread and butter 
>>application"? 
> 
> Come on Andreas! It is a small project from the world I come from. They are 
> working on the 
> implementation and conversion of a Java app into qooxdoo gui. It is bread and 
> butter, meaning 
> here is not a very high tech level or innovative level. Standard things which 
> have been done before. 
> No rocket science! 
> 
>>Don't panic! Nobody is talking about making your app code publicly 
>>available. In most open source environments nobody would expect that, so 
>>why would you do? 
>  
> You must be ironic here and it is not appreciated. 
> ...

... and the mail goes on with complaints about irony and the like.

I have seen no irony in the initial mail, am guessing the response could start 
a flame war, but can't simply shut up.

I'll keep my shirt on, and just say this: there'll always be people or 
companies using an open source product which don't have the attitude, mindset 
and/or experience required to contribute to the development of the product and 
growth of the community that forms around that product. IMO it's not the most 
efficient way to spend time and effort trying to change that, to say the least. 
Just my personal opinion.

br,

flj


--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Re: [qooxdoo-devel] (off topic?) Qooxdoo's ecossystem question

2010-09-14 Thread John Spackman

Ah, not so simple then :)

I might try it out in a few months if work slacks off, thanks for the info.

john

On 14/09/2010 10:16, "thron7"  wrote:

>
>
>On 09/14/2010 10:06 AM, John Spackman wrote:
>> Hi Thomas,
>> 
>> Brill, that sounds exactly like it.  I can't quite tell though - does
>>the
>> generator "source-hybrid" work yet?
>
>Nope, not implemented yet.
>
>> I.e. The bug's still open because
>> there's some assembly required?
>
>Yes, quite. For one, the desired "source" build (basically a 'cat' of
>the source files into a single one) is currently not supported by the
>generator. I want to extend this idea so that you can have any set of
>classes that goes into a build at any level of optimization.
>
>Then there is the issue of packaging, so that sets of classes go into a
>common package, the single class staying in its source file being an
>extreme of that. You need configuration support for that. The current
>"packages" key does not provide means to determine exactly which classes
>go together in a common package, and is rather driven by concerns of
>load order than by which package remains stable and which might change.
>
>The third issue is that of "linking". The generator is currently not
>prepared to include packages in a build run that stem from a previous
>run, and are pre-built in that sense. You could re-create the "stable"
>packages every time you run a build, but I think this would be missing
>at least some of the point. Also, there are other scenarios where
>including pre-built packages would be interesting, so I think this
>should be solved in general. But this also raises the question what the
>generator needs to know about a pre-built package, what it can infer
>from the config or the file itself (e.g. the list of contained classes).
>And so forth and so on :).
>
>T.
>
>> 
>> Thanks
>> John
>> 
>> On 14/09/2010 08:25, "thron7"  wrote:
>> 
>>>
>>>
>>> On 09/14/2010 08:29 AM, John Spackman wrote:
 Hi all,

 Re: "One big build file" - when you develop on a local disk, this is
 much
 less relevant than when you use a web server backend.  There are over
 400
 files in an average application and each one causes a request to the
 server; if I refresh the app I'm working on now there are 474
requests,
 99% of which are "304 not modified" responses.

 This adds up to 15 seconds of network comms for source builds, and is
 frustrating - in this case it would be much better to have all Qx
 scripts
 as a single or a few files (ideally defined by config.json).
>>>
>>> What you want is http://bugzilla.qooxdoo.org/show_bug.cgi?id=2008,
>>> but mind that this is *not* the same as working with a tools-free
>>> version of qooxdoo.
>>>
>>> T.
>>>
>>> 
>>>
>>>--
>>> 
>>> Start uncovering the many advantages of virtual appliances
>>> and start using them to simplify application deployment and
>>> accelerate your shift to cloud computing.
>>> http://p.sf.net/sfu/novell-sfdev2dev
>>> ___
>>> qooxdoo-devel mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>> 
>> 
>> 
>> 
>> 
>>-
>>-
>> Start uncovering the many advantages of virtual appliances
>> and start using them to simplify application deployment and
>> accelerate your shift to cloud computing.
>> http://p.sf.net/sfu/novell-sfdev2dev
>> ___
>> qooxdoo-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>> 
>> 
>
>--
>
>Start uncovering the many advantages of virtual appliances
>and start using them to simplify application deployment and
>accelerate your shift to cloud computing.
>http://p.sf.net/sfu/novell-sfdev2dev
>___
>qooxdoo-devel mailing list
>[email protected]
>https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel




--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Re: [qooxdoo-devel] (off topic?) Qooxdoo's ecossystem question

2010-09-14 Thread panyasan


The exchange has become rather heated and it would certainly be a good idea
to step back a bit. The theme of the discussion is already familiar and has
been discussed before. There is no use in a war over the definition of "open
source" and "community". As to the latter, I am "community" as well without
having the kind of problems others seem to have with the current state of
qooxdoo. People have all kinds of expectations and use cases and often one
mistakes one's own position to reflect the "community's" position. 

What we have is a software development infrastructure that "just works",
with an excellent support. It is stable, useful and free. What more, alas,
can you expect?  What is the concrete, realistic, empirically measurable
benefit people expect from making it "more open", what does this mean *in
practice*? I really don't understand. 

C. 
-- 
View this message in context: 
http://qooxdoo.678.n2.nabble.com/off-topic-Qooxdoo-s-ecossystem-question-tp5516947p5530670.html
Sent from the qooxdoo mailing list archive at Nabble.com.

--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Re: [qooxdoo-devel] (off topic?) Qooxdoo's ecossystem question

2010-09-14 Thread Stefan Andersson


Hej Andreas!

>Wait, you say at your business 21 developers work 100% of their time on
>such a qooxdoo app, and you call it a "simple bread and butter
>application"?

Come on Andreas! It is a small project from the world I come from. They are 
working on the 
implementation and conversion of a Java app into qooxdoo gui. It is bread and 
butter, meaning 
here is not a very high tech level or innovative level. Standard things which 
have been done before.
No rocket science!

>Don't panic! Nobody is talking about making your app code publicly
>available. In most open source environments nobody would expect that, so
>why would you do?

You must be ironic here and it is not appreciated.

>I was talking about telling the community what large-scale qoxodoo app
>development you do. Seriously, you successfully create and maintain a
>1,200,000 LOC qooxdoo app with a team of 21 full-time people and you
>don't even disclose the name of the company or a description and/or
>screenshot of the app in the real-life examples? Being silent doesn't
>help qooxdoo at all.

We will tell when in due time if we find it appropriate. It is nothing you have 
information about
to take a decision about. In this part we have never had the ambition to help 
qooxdoo, but you
seem to have that.

>Well, fair enough. That is how open source should also be able to work
>(and that's why we make exactly that possible by choosing 2 liberal,
>approved licenses (LGPL/EPL), and not GPL).

It is interpreted as irony and is not appreciated. Small sticky comments never 
grow in a good way.

>You actually don't seem to care about supporting and promoting qooxdoo
>by telling the world about your success story? Instead you demand more
>"openness" of qooxdoo? To whom should this project (core team, 1&1,
>contributors, community) be more open? You don't give anyone a clue of
>who you are.

This again is another insinuation which shows the mindset. It is not 
appreciated at all.

I don't think you have read our previous proposal about adding dedicated labour 
resources to the project. 

We do not claim that we have a success story. We only try to do what we do the 
best way we can.

1&1 has chosen to go open source. We have not and we do not need to reveal 
anything we don't want to.
If you don't like that, it is your problem. 

When it comes to qooxdo: We have NEVER demanded that qooxdoo should be more 
open. We have SUGGESTED
qooxdoo to become more open. There is a big difference here. Our suggestion is 
that it becomes more open
to the community, cause then the real power of the community can be used and 
not only as bug finders as 
of today.

>Perfect. If 1&1 would have that very mind set, qooxdoo as it is simply
>wouldn't exist. Instead, the company and the core team puts a lot of
>effort into providing an enterprise-level framework. Totally for free to
>anyone. To me that is open source spirit.

Come on! This does not work on me. All have reasons for what they are doing. 
Don't you use qooxdoo
in your products and homepage? You do and as long as you do it is not total 
generosity as you try 
it to become. But is is ok for us. But don't claim that it is charity...

What you provide is in almost all ways something 1&1 wants. ELse I am sure that 
1&1 would stop 
financing the project. It is also fine to us, but don't claim anything else.

>That's it? Ok, so you simply are a consumer of qooxdoo, right?

As 1&1 and all other here too. Some people contribute more than others, that is 
a community. And by 
lowering the thresholds of contribution to the core the community will become 
more vivid.

>Not the future will tell, you would have to tell.

No, future of qooxdoo will tell and the directions 1&1 wants to see.

>I'm sure also just "a few things" out of your codebase would be
>appreciated by the qooxdoo community. I don't see any uncertainty about
>the "policies of openness". There are new contributions made to qooxdoo
>every week. Why wouldn't you be able to contribute?

Most is bread and butter and not useful to others in parts, but, yes, we have 
parts which might be interesting
to others, maybe... What you see is not the base of our decisions. You really 
have to understand that,
as you don't have the information we have.

>I suggest you become a contributor: you sign the regular license
>agreements, we then set you up with full SVN commit rights to
>qooxdoo-contrib, and then you can start right away. It's all in the
>docs, maybe you may want to reread the following:
>http://qooxdoo.org/contrib
>http://qooxdoo.org/documentation/general/faq
>http://qooxdoo.org/documentation/general/committers_guide

>If there is anything unclear, please let me know. Looking forward in you
>becoming an active part of the qooxdoo ecosystem.

Andreas, we have seen and read that. When we have taken the decision to 
whatever it is and we feel that
the policies are more open, then we would gladly be contributing with pure 
code. As it is not, it 
is not clear.

We would ap

Re: [qooxdoo-devel] (off topic?) Qooxdoo's ecossystem question

2010-09-14 Thread Andreas Ecker

Hej Stefan!

On Tue, 2010-09-14 at 11:45 +0200, Stefan Andersson wrote:
> Hej Andreas!
> 
> >> We have developed about 1,200,000 lines of "qooxdoo" code and
> >> converted a system which soon will "fly"... We are satisfied about
> >> it. 
> 
> >Wow, this is really impressive! Are you sure you really talk about
> >"1,200,000 lines of code"? Even if that includes comments, this would
> >make it by far the largest qooxdoo application at least I know of.
> 
> Including comments. It is a "simple" bread and butter application, converted 
> from Java GUI.

Wait, you say at your business 21 developers work 100% of their time on
such a qooxdoo app, and you call it a "simple bread and butter
application"?

> >I guess everyone would really interested in getting to know more about
> >this huge qooxdoo project of yours. You repeatedly talk on the mailing
> >list about "openness", being more transparent and so on. Unfortunately
> >nobody (at least not me) knows either about your company or your
> >project. :-( Why wouldn't you want to share it with the qooxdoo
> >community??
> 
> Certainly, but it is not an open source project. This passing of yours is 
> repelling and I would 
> appreciate more diplomacy.

Don't panic! Nobody is talking about making your app code publicly
available. In most open source environments nobody would expect that, so
why would you do?

I was talking about telling the community what large-scale qoxodoo app
development you do. Seriously, you successfully create and maintain a
1,200,000 LOC qooxdoo app with a team of 21 full-time people and you
don't even disclose the name of the company or a description and/or
screenshot of the app in the real-life examples? Being silent doesn't
help qooxdoo at all.

Well, fair enough. That is how open source should also be able to work
(and that's why we make exactly that possible by choosing 2 liberal,
approved licenses (LGPL/EPL), and not GPL).

You actually don't seem to care about supporting and promoting qooxdoo
by telling the world about your success story? Instead you demand more
"openness" of qooxdoo? To whom should this project (core team, 1&1,
contributors, community) be more open? You don't give anyone a clue of
who you are.

> Our development is not a question for the community and will never be. We 
> have in qooxdoo found
> an excellent base for the web gui and that's it.

Perfect. If 1&1 would have that very mind set, qooxdoo as it is simply
wouldn't exist. Instead, the company and the core team puts a lot of
effort into providing an enterprise-level framework. Totally for free to
anyone. To me that is open source spirit.

> We have in qooxdoo found
> an excellent base for the web gui and that's it.

That's it? Ok, so you simply are a consumer of qooxdoo, right?

> >> The support is fast and mostly accurate. The core team is mostly very
> >> skilled in its answers. But we would never choose qooxdoo for such a
> >> big project without knowing we have our own resources if qooxdoo dies
> >> or if the qooxdoo team disappears in some or the other way. Too big
> >> investment and too big risk, if we wouldn't have the resources by
> >> ourselves.
> 
> >Sounds like you got many development resources behind your qooxdoo
> >project. That is great, and an excellent opportunity for you to
> >contribute back to the project. Have you ever thought of adding regular
> >contributions to qooxdoo-contrib? It's a pretty straightforward process,
> >you certainly have seen the recent contributions, so it also shouldn't
> >be hard for your team. If you need any help with qooxdoo-contrib,
> >http://contrib.qooxdoo.org, please let me know.
> 
> 21 people 100% of time.
> 
> We have chosen to contribute by asking questions, correcting bugs, adding 
> ideas and getting things 
> cleared out by the core team.
> 
> If we will get more involved future will tell.

Not the future will tell, you would have to tell.

> Yes, we have a few things we could share with the community as contributions, 
> but until it is clear 
> how the policies of openness is we will wait for the right moment.

I'm sure also just "a few things" out of your codebase would be
appreciated by the qooxdoo community. I don't see any uncertainty about
the "policies of openness". There are new contributions made to qooxdoo
every week. Why wouldn't you be able to contribute?

I suggest you become a contributor: you sign the regular license
agreements, we then set you up with full SVN commit rights to
qooxdoo-contrib, and then you can start right away. It's all in the
docs, maybe you may want to reread the following:
http://qooxdoo.org/contrib
http://qooxdoo.org/documentation/general/faq
http://qooxdoo.org/documentation/general/committers_guide

If there is anything unclear, please let me know. Looking forward in you
becoming an active part of the qooxdoo ecosystem.

Andreas

-- 
Andreas Ecker
Project Lead
http://qooxdoo.org

--
Start

Re: [qooxdoo-devel] (off topic?) Qooxdoo's ecossystem question

2010-09-14 Thread Fritz Zaucker

On Tue, 14 Sep 2010, Stefan Andersson wrote:

>> You might have a problem with 1&1's stand-point, but you are at the same
>> point "punishing" everybody by not sharing potentially useful things.

> 1&1 doesn't share ALL useful things of their application development!

Who said something about sharing ALL? You don't even share the name of your
company ...

> I haven't seen you doing the same.

Search for oetiker or tobi on http://qooxdoo.org/contrib/project

Cheers,
Fritz

-- 
Oetiker+Partner AG  tel: +41 62 775 9903 (direct)
Fritz Zaucker+41 62 775 9900 (switch board)
Aarweg 15+41 79 675 0630 (mobile)
CH-4600 Olten   fax: +41 62 775 9905
Schweiz web: www.oetiker.ch

--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Re: [qooxdoo-devel] (off topic?) Qooxdoo's ecossystem question

2010-09-14 Thread Stefan Andersson


Fritz,

No one is attacking your opinions. If I don't remember wrong you were replying 
on my post and not vice versa in the start. Please, keep all those things out 
of the discussion!
>>> I guess everyone would really interested in getting to know more about
>>> this huge qooxdoo project of yours. You repeatedly talk on the mailing
>>> list about "openness", being more transparent and so on. Unfortunately
>>> nobody (at least not me) knows either about your company or your project.
>>> :-( Why wouldn't you want to share it with the qooxdoo community??
>>
>> Certainly, but it is not an open source project. This passing of yours is
>> repelling and I would appreciate more diplomacy.

>Look who is talking ...

?
I think you have misunderstood my point!

>> Yes, we have a few things we could share with the community as
>> contributions, but until it is clear how the policies of openness is we
>> will wait for the right moment.

>Qooxdoo is available to you without attaching any such conditions ...

not correct!

>You might have a problem with 1&1's stand-point, but you are at the same
>point "punishing" everybody by not sharing potentially useful things.
I don't have any problem with 1&1 or their standpoint at all. It is an 
excellent company. Everyone can choose as they wish. But it does not stop me to 
answer the question why we can not only publish contributions without knowing 
about the policies. The same did 1&1 and all who cares about it! 1&1 doesn't 
share ALL useful things of their application development! I haven't seen you 
doing the same.

Now maybe it is in place that you respect our standpoint?

Stefan
  --
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev___
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Re: [qooxdoo-devel] (off topic?) Qooxdoo's ecossystem question

2010-09-14 Thread Fritz Zaucker

On Tue, 14 Sep 2010, Stefan Andersson wrote:

>> I guess everyone would really interested in getting to know more about
>> this huge qooxdoo project of yours. You repeatedly talk on the mailing
>> list about "openness", being more transparent and so on. Unfortunately
>> nobody (at least not me) knows either about your company or your project.
>> :-( Why wouldn't you want to share it with the qooxdoo community??
>
> Certainly, but it is not an open source project. This passing of yours is
> repelling and I would appreciate more diplomacy.

Look who is talking ...

> Yes, we have a few things we could share with the community as
> contributions, but until it is clear how the policies of openness is we
> will wait for the right moment.

Qooxdoo is available to you without attaching any such conditions ...

You might have a problem with 1&1's stand-point, but you are at the same
point "punishing" everybody by not sharing potentially useful things.

Cheers,
Fritz

-- 
Oetiker+Partner AG  tel: +41 62 775 9903 (direct)
Fritz Zaucker+41 62 775 9900 (switch board)
Aarweg 15+41 79 675 0630 (mobile)
CH-4600 Olten   fax: +41 62 775 9905
Schweiz web: www.oetiker.ch

--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Re: [qooxdoo-devel] (off topic?) Qooxdoo's ecossystem question

2010-09-14 Thread Stefan Andersson


Hej Andreas!

>> We have developed about 1,200,000 lines of "qooxdoo" code and
>> converted a system which soon will "fly"... We are satisfied about
>> it. 

>Wow, this is really impressive! Are you sure you really talk about
>"1,200,000 lines of code"? Even if that includes comments, this would
>make it by far the largest qooxdoo application at least I know of.

Including comments. It is a "simple" bread and butter application, converted 
from Java GUI.

>The JS framework of qooxdoo has about 300,000 NCLOC (non-comment) in
>total. A large-scale app like GMX.com is also about that size in
>addition to the framework classes. 

If you say so.

>I guess everyone would really interested in getting to know more about
>this huge qooxdoo project of yours. You repeatedly talk on the mailing
>list about "openness", being more transparent and so on. Unfortunately
>nobody (at least not me) knows either about your company or your
>project. :-( Why wouldn't you want to share it with the qooxdoo
>community??

Certainly, but it is not an open source project. This passing of yours is 
repelling and I would 
appreciate more diplomacy.

Our development is not a question for the community and will never be. We have 
in qooxdoo found
an excellent base for the web gui and that's it.

>> The support is fast and mostly accurate. The core team is mostly very
>> skilled in its answers. But we would never choose qooxdoo for such a
>> big project without knowing we have our own resources if qooxdoo dies
>> or if the qooxdoo team disappears in some or the other way. Too big
>> investment and too big risk, if we wouldn't have the resources by
>> ourselves.

>Sounds like you got many development resources behind your qooxdoo
>project. That is great, and an excellent opportunity for you to
>contribute back to the project. Have you ever thought of adding regular
>contributions to qooxdoo-contrib? It's a pretty straightforward process,
>you certainly have seen the recent contributions, so it also shouldn't
>be hard for your team. If you need any help with qooxdoo-contrib,
>http://contrib.qooxdoo.org, please let me know.

21 people 100% of time.

We have chosen to contribute by asking questions, correcting bugs, adding ideas 
and getting things 
cleared out by the core team.

If we will get more involved future will tell.

Yes, we have a few things we could share with the community as contributions, 
but until it is clear 
how the policies of openness is we will wait for the right moment.

Bye for now Andreas,

Stefan


Bye,

Andreas

-- 
Andreas Ecker
Project Lead
http://qooxdoo.org
  --
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev___
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Re: [qooxdoo-devel] (off topic?) Qooxdoo's ecossystem question

2010-09-14 Thread Andreas Ecker

Hi Stefan!

On Fri, 2010-09-10 at 09:38 +0200, Stefan Andersson wrote:
> [...]
> 
> Even though this insecurity due to the market and fame, we chose
> qooxdoo because the code has been fairly well documented, the
> structure is robust and it is technically the best. It still has a lot
> of things to improve, but already now it is the best. 

Great to see your happy with it, at least from a technical pov.

> We have developed about 1,200,000 lines of "qooxdoo" code and
> converted a system which soon will "fly"... We are satisfied about
> it. 

Wow, this is really impressive! Are you sure you really talk about
"1,200,000 lines of code"? Even if that includes comments, this would
make it by far the largest qooxdoo application at least I know of.

The JS framework of qooxdoo has about 300,000 NCLOC (non-comment) in
total. A large-scale app like GMX.com is also about that size in
addition to the framework classes. 

I guess everyone would really interested in getting to know more about
this huge qooxdoo project of yours. You repeatedly talk on the mailing
list about "openness", being more transparent and so on. Unfortunately
nobody (at least not me) knows either about your company or your
project. :-( Why wouldn't you want to share it with the qooxdoo
community??

> The support is fast and mostly accurate. The core team is mostly very
> skilled in its answers. But we would never choose qooxdoo for such a
> big project without knowing we have our own resources if qooxdoo dies
> or if the qooxdoo team disappears in some or the other way. Too big
> investment and too big risk, if we wouldn't have the resources by
> ourselves.

Sounds like you got many development resources behind your qooxdoo
project. That is great, and an excellent opportunity for you to
contribute back to the project. Have you ever thought of adding regular
contributions to qooxdoo-contrib? It's a pretty straightforward process,
you certainly have seen the recent contributions, so it also shouldn't
be hard for your team. If you need any help with qooxdoo-contrib,
http://contrib.qooxdoo.org, please let me know.

Bye,

Andreas

-- 
Andreas Ecker
Project Lead
http://qooxdoo.org

--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Re: [qooxdoo-devel] (off topic?) Qooxdoo's ecossystem question

2010-09-14 Thread thron7

On 09/14/2010 10:06 AM, John Spackman wrote:
> Hi Thomas,
> 
> Brill, that sounds exactly like it.  I can't quite tell though - does the
> generator "source-hybrid" work yet?

Nope, not implemented yet.

> I.e. The bug's still open because
> there's some assembly required?

Yes, quite. For one, the desired "source" build (basically a 'cat' of
the source files into a single one) is currently not supported by the
generator. I want to extend this idea so that you can have any set of
classes that goes into a build at any level of optimization.

Then there is the issue of packaging, so that sets of classes go into a
common package, the single class staying in its source file being an
extreme of that. You need configuration support for that. The current
"packages" key does not provide means to determine exactly which classes
go together in a common package, and is rather driven by concerns of
load order than by which package remains stable and which might change.

The third issue is that of "linking". The generator is currently not
prepared to include packages in a build run that stem from a previous
run, and are pre-built in that sense. You could re-create the "stable"
packages every time you run a build, but I think this would be missing
at least some of the point. Also, there are other scenarios where
including pre-built packages would be interesting, so I think this
should be solved in general. But this also raises the question what the
generator needs to know about a pre-built package, what it can infer
from the config or the file itself (e.g. the list of contained classes).
And so forth and so on :).

T.

> 
> Thanks
> John
> 
> On 14/09/2010 08:25, "thron7"  wrote:
> 
>>
>>
>> On 09/14/2010 08:29 AM, John Spackman wrote:
>>> Hi all,
>>>
>>> Re: "One big build file" - when you develop on a local disk, this is
>>> much
>>> less relevant than when you use a web server backend.  There are over
>>> 400
>>> files in an average application and each one causes a request to the
>>> server; if I refresh the app I'm working on now there are 474 requests,
>>> 99% of which are "304 not modified" responses.
>>>
>>> This adds up to 15 seconds of network comms for source builds, and is
>>> frustrating - in this case it would be much better to have all Qx
>>> scripts
>>> as a single or a few files (ideally defined by config.json).
>>
>> What you want is http://bugzilla.qooxdoo.org/show_bug.cgi?id=2008,
>> but mind that this is *not* the same as working with a tools-free
>> version of qooxdoo.
>>
>> T.
>>
>> --
>> 
>> Start uncovering the many advantages of virtual appliances
>> and start using them to simplify application deployment and
>> accelerate your shift to cloud computing.
>> http://p.sf.net/sfu/novell-sfdev2dev
>> ___
>> qooxdoo-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
> 
> 
> 
> 
> --
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> ___
> qooxdoo-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
> 
> 

--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Re: [qooxdoo-devel] (off topic?) Qooxdoo's ecossystem question

2010-09-14 Thread Petr Kobalíček

Hi Thomas,

I don't know if some of your arguments are valid. Qooxdoo is different
to all javascript libraries available. I'd like to say here that
qooxdoo is not java and it will never be. Qooxdoo packages are not
needed at all and I don't know if restricting users to have exactly
"one" politically correct file structure is right. How others are
doing it? Others which are using dojo, extjs or smartclient? There are
using packages too, but conception is different.

Also the one-big-js file is not so big as it seems. How many qooxdoo
classes are compiled in usual qooxdoo application? Qooxdoo all-in-one
is about 1.2MB. My experiences are that if you use table, list and
tree widgets then qooxdoo size will grow up to about 1MB. 200kB is
really not big price to have comfortable debugging, deployment, and to
not worry about qooxdoo-generator.

> What about the people we lose *because* of the single file, as they say
> "Uh, qooxdoo is *so ridiculously fat*, you can't really use it!"?!

Qooxdoo is fat, you should make peace with it;)

Best regards
Petr

On Tue, Sep 14, 2010 at 9:58 AM, thron7  wrote:
>
>> Download one js big file, preoptimized as mush as possible, and play
> with
>> qooxdoo. No need for Python, no need for a build.
>
> You need to think this through. Where would application code go? As you
> don't use the build system, you can't put it into class files under some
> "source/class" root directory. So you need to put it into the
> index.html, directly and all of it. And you need to order it correctly,
> so that class
> dependencies resolve. What about application startup? So you have to add
> more code at the bottom of the class code that fires up qooxdoo's
> application start. The use of own images will be impeded, as there is no
> build step to create resource information for them.
>
> As you might see, this is an entirely different programming model. Maybe
> this is still acceptable from your point of view, but who will support
> this? Who will be guiding all the newcomers in the proper way to use it?
>
>> Now after few months, one can without changing a line of code switch
>> to qooxdoo with a build and the same code will run more quickly.
>> Isn't that great ?
>
> It will not work, as all of your code is in a single index.html. You
> have to cut out the individual classes and put them into their proper
> path, matching name spaces. Yes, it's doable, but when will you do it,
> given that the application has long been put into production? When you
> have 20 application classes? 30? 50?
>
>> Unfortunately, you currently have to bother with python toolchain
>> even before you know qooxdoo is cool. That's one big reason that, I
>> think, prevent a better qooxdoo adoption.
>
> What about the people we lose *because* of the single file, as they say
> "Uh, qooxdoo is *so ridiculously fat*, you can't really use it!"?!
>
>> no. I think qooxdoo would have better adoption with an optional
>> build
> (python
>> or not).
>
> One thing I personally would find as interesting as a single big file
> would be an online build service :).
>
>> do like us ;-) To be honest, there is a link : that qooxdoo big file
>> would be what we want to speed up the overall thing.
>
> We've been through that, and I tried to tell you that I wouldn't expect
> much performance gain from that, but never mind.
>
> And if you are so convinced, why don't you just do it?! The means are
> all there. Go ahead, create your single qooxdoo library, and then tell
> us what the outcome was.
>
> T.
>
> --
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> ___
> qooxdoo-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>

--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Re: [qooxdoo-devel] (off topic?) Qooxdoo's ecossystem question

2010-09-14 Thread John Spackman

Hi Thomas,

Brill, that sounds exactly like it.  I can't quite tell though - does the
generator "source-hybrid" work yet? I.e. The bug's still open because
there's some assembly required?

Thanks
John

On 14/09/2010 08:25, "thron7"  wrote:

>
>
>On 09/14/2010 08:29 AM, John Spackman wrote:
>> Hi all,
>> 
>> Re: "One big build file" - when you develop on a local disk, this is
>>much
>> less relevant than when you use a web server backend.  There are over
>>400
>> files in an average application and each one causes a request to the
>> server; if I refresh the app I'm working on now there are 474 requests,
>> 99% of which are "304 not modified" responses.
>> 
>> This adds up to 15 seconds of network comms for source builds, and is
>> frustrating - in this case it would be much better to have all Qx
>>scripts
>> as a single or a few files (ideally defined by config.json).
>
>What you want is http://bugzilla.qooxdoo.org/show_bug.cgi?id=2008,
>but mind that this is *not* the same as working with a tools-free
>version of qooxdoo.
>
>T.
>
>--
>
>Start uncovering the many advantages of virtual appliances
>and start using them to simplify application deployment and
>accelerate your shift to cloud computing.
>http://p.sf.net/sfu/novell-sfdev2dev
>___
>qooxdoo-devel mailing list
>[email protected]
>https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel




--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Re: [qooxdoo-devel] (off topic?) Qooxdoo's ecossystem question

2010-09-14 Thread thron7


> Download one js big file, preoptimized as mush as possible, and play
with
> qooxdoo. No need for Python, no need for a build.

You need to think this through. Where would application code go? As you
don't use the build system, you can't put it into class files under some
"source/class" root directory. So you need to put it into the
index.html, directly and all of it. And you need to order it correctly,
so that class
dependencies resolve. What about application startup? So you have to add
more code at the bottom of the class code that fires up qooxdoo's
application start. The use of own images will be impeded, as there is no
build step to create resource information for them.

As you might see, this is an entirely different programming model. Maybe
this is still acceptable from your point of view, but who will support
this? Who will be guiding all the newcomers in the proper way to use it?

> Now after few months, one can without changing a line of code switch
> to qooxdoo with a build and the same code will run more quickly. 
> Isn't that great ?

It will not work, as all of your code is in a single index.html. You
have to cut out the individual classes and put them into their proper
path, matching name spaces. Yes, it's doable, but when will you do it,
given that the application has long been put into production? When you
have 20 application classes? 30? 50?

> Unfortunately, you currently have to bother with python toolchain
> even before you know qooxdoo is cool. That's one big reason that, I
> think, prevent a better qooxdoo adoption.

What about the people we lose *because* of the single file, as they say
"Uh, qooxdoo is *so ridiculously fat*, you can't really use it!"?!

> no. I think qooxdoo would have better adoption with an optional
> build
(python
> or not).

One thing I personally would find as interesting as a single big file
would be an online build service :).

> do like us ;-) To be honest, there is a link : that qooxdoo big file
> would be what we want to speed up the overall thing.

We've been through that, and I tried to tell you that I wouldn't expect
much performance gain from that, but never mind.

And if you are so convinced, why don't you just do it?! The means are
all there. Go ahead, create your single qooxdoo library, and then tell
us what the outcome was.

T.

--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Re: [qooxdoo-devel] (off topic?) Qooxdoo's ecossystem question

2010-09-14 Thread thron7



On 09/14/2010 08:29 AM, John Spackman wrote:
> Hi all,
> 
> Re: "One big build file" - when you develop on a local disk, this is much
> less relevant than when you use a web server backend.  There are over 400
> files in an average application and each one causes a request to the
> server; if I refresh the app I'm working on now there are 474 requests,
> 99% of which are "304 not modified" responses.
> 
> This adds up to 15 seconds of network comms for source builds, and is
> frustrating - in this case it would be much better to have all Qx scripts
> as a single or a few files (ideally defined by config.json).

What you want is http://bugzilla.qooxdoo.org/show_bug.cgi?id=2008,
but mind that this is *not* the same as working with a tools-free
version of qooxdoo.

T.

--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Re: [qooxdoo-devel] (off topic?) Qooxdoo's ecossystem question

2010-09-14 Thread thron7



On 09/13/2010 11:41 PM, Jean-Noël Rivasseau wrote:
> http://bugzilla.qooxdoo.org/show_bug.cgi?id=2962

It's a P2 for 1.3, so the odds are really good ;).

T.

> 
> On Mon, Sep 13, 2010 at 8:00 PM, thron7  wrote:
>>> The only thing I wish for Qx is faster development, faster bugfixing.
>>> Especially with bugs that have patches. There is one bug on the
>>> bugzilla that has a patch and is absolutely essential for us, but it
>>> is still not applied upstream.
>>
>> Which one is that?
>>
>>
>>
>>
>> --
>> Start uncovering the many advantages of virtual appliances
>> and start using them to simplify application deployment and
>> accelerate your shift to cloud computing
>> http://p.sf.net/sfu/novell-sfdev2dev
>> ___
>> qooxdoo-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
> 
> --
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> ___
> qooxdoo-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
> 
> 

--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Re: [qooxdoo-devel] (off topic?) Qooxdoo's ecossystem question

2010-09-13 Thread Daniel Wagner

Yeah, I've been sitting on that one for a while. Didn't want to apply it 
without understanding what it does. I'll try to take a closer look some 
time this week.

Regards,
Daniel

Jean-Noël Rivasseau schrieb:
> http://bugzilla.qooxdoo.org/show_bug.cgi?id=2962
> 
> On Mon, Sep 13, 2010 at 8:00 PM, thron7  wrote:
>>> The only thing I wish for Qx is faster development, faster bugfixing.
>>> Especially with bugs that have patches. There is one bug on the
>>> bugzilla that has a patch and is absolutely essential for us, but it
>>> is still not applied upstream.
>> Which one is that?
>>
>>
>>
>>
>> --
>> Start uncovering the many advantages of virtual appliances
>> and start using them to simplify application deployment and
>> accelerate your shift to cloud computing
>> http://p.sf.net/sfu/novell-sfdev2dev
>> ___
>> qooxdoo-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
> 
> --
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> ___
> qooxdoo-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
> 
> 

--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Re: [qooxdoo-devel] (off topic?) Qooxdoo's ecossystem question

2010-09-13 Thread John Spackman

Hi all,

Re: "One big build file" - when you develop on a local disk, this is much
less relevant than when you use a web server backend.  There are over 400
files in an average application and each one causes a request to the
server; if I refresh the app I'm working on now there are 474 requests,
99% of which are "304 not modified" responses.

This adds up to 15 seconds of network comms for source builds, and is
frustrating - in this case it would be much better to have all Qx scripts
as a single or a few files (ideally defined by config.json).

It probably makes Qx look really slow and clunky when you first use it.

John

On 13/09/2010 17:59, "Jean-Baptiste BRIAUD -- Novlog"
 wrote:

>
>On 13 sept. 2010, at 18:47, Stefan Volbers wrote:
>
>> Hi Jean-Baptiste,
>> 
>> if I may intercept in this discussion:
>> 
>Sure, you're welcome !
>
>> I don't believe that qooxdoo'd get a better 'market share' if the
>>python 
>> build system'd disappear.
>Optional rather than mandatory like now. That's all I would like.
>I don't want the build to disappear.
>How would we have the optimized version then ?
>> You may not know that prior to qooxdoo 0.8 (or was it 0.7?) the build
>> system relied on 'make' instead of python, which was a disadvantage for
>> the windows platform, as one had to make use of cygwin to get access to
>> gnu make asf.
>I was thinking about a version of qooxdoo that doesn't need build at all.
>Make is not a good choice for qooxdoo, as you said, its a problem for
>Windows.
>Only multiplateform should be OK.
>Python is fine as long as there is a way for newcomers to avoid any build
>at all.
>
>Download one js big file, preoptimized as mush as possible, and play with
>qooxdoo.
>No need for Python, no need for a build.
>
>Now after few months, one can without changing a line of code switch to
>qooxdoo with a build and the same code will run more quickly.
>Isn't that great ?
>
>*** No constraint to start and the power just when you need it. ***
>
>Unfortunately, you currently have to bother with python toolchain even
>before you know qooxdoo is cool.
>That's one big reason that, I think, prevent a better qooxdoo adoption.
>
>> 
>> I cannot tell whether qooxdoo's adoption significantly increased since
>> switching to python (or even dropped). In fact, I don't really care, as
>> I can see the advantage of using qooxdoo, and myself, I am gonna adopt
>> the build system anyway.
>> 
>> Regarding the discussion so far:
>> You claim that qooxdoo has bad adoption since it makes use of a python
>> build system;
>no.
>I think qooxdoo would have better adoption with an optional build (python
>or not).
>
>> also you claim the build system is too slow for your work
>> flow.
>That's true for us but it is another discussion since "we are special".
>Even if I'm French, I hope I'm not arrogant enough to ask the community
>to do like us ;-)
>To be honest, there is a link : that qooxdoo big file would be what we
>want to speed up the overall thing.
>
>
>
>
>
>--
>
>Start uncovering the many advantages of virtual appliances
>and start using them to simplify application deployment and
>accelerate your shift to cloud computing
>http://p.sf.net/sfu/novell-sfdev2dev
>___
>qooxdoo-devel mailing list
>[email protected]
>https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel




--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Re: [qooxdoo-devel] (off topic?) Qooxdoo's ecossystem question

2010-09-13 Thread Jean-Noël Rivasseau

http://bugzilla.qooxdoo.org/show_bug.cgi?id=2962

On Mon, Sep 13, 2010 at 8:00 PM, thron7  wrote:
>> The only thing I wish for Qx is faster development, faster bugfixing.
>> Especially with bugs that have patches. There is one bug on the
>> bugzilla that has a patch and is absolutely essential for us, but it
>> is still not applied upstream.
>
> Which one is that?
>
>
>
>
> --
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing
> http://p.sf.net/sfu/novell-sfdev2dev
> ___
> qooxdoo-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Re: [qooxdoo-devel] (off topic?) Qooxdoo's ecossystem question

2010-09-13 Thread thron7

> Stefan,
>
> Today Stefan Volbers wrote:
>
>> You may hire a C++ developer, who rewrites the build system for your
>> needs in fast optimized code for your favourite platform (I assume
>> you're a mac guy?).
>
> Only a gut feeling, but I wonder if the build performance is realy
> cpu bound or rather io-bound due to the many files qooxdoo has to
> touch ... even with the cache ... or to put it differently there
> may well be low hanging fruit to pick in the generator without
> major rewriting if one puts a profiler to work ... (only guessing,
> maybe thomas has done that already).

I can confirm CPU boundedness. I hang out in the profiler a lot. There
might be a few corners where I/O could be improved, but the main culprit
is CPU.

T.

>
> cheers
> tobi
>
> --
> Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
> http://it.oetiker.ch [email protected] ++41 62 775 9902 / sb: -9900
>
> --
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing
> http://p.sf.net/sfu/novell-sfdev2dev
> ___
> qooxdoo-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
>
>



--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing
http://p.sf.net/sfu/novell-sfdev2dev
___
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Re: [qooxdoo-devel] (off topic?) Qooxdoo's ecossystem question

2010-09-13 Thread Fritz Zaucker


On Mon, 13 Sep 2010, Jean-Noël Rivasseau wrote:


I disagre with Jean-Baptiste about what needs to be done to trigger
greater adoption.  Personally I think Python is a great choice for a build
system and I had no problems at all with this as a newcomer to Qx.


And there is the demo browser, the playground, the showcase to find out what
Qooxdoo can do even without downloading anything at all.


There are btw probably more companies in France using Qx that what you may
think (we are one of such companies), for a simple reason that was already
outlined: from a technical perspective, Qx rocks.


I think it would be nice if all Qooxdoo users would put up a their use cases
on http://qooxdoo.org/community/real_life_examples


I think that's actually one of the reason that it's hard to find paid
consultancy on Qx: the framework is so good, and the support on the ML
is so good, who needs to pay a consultant ? ;)


That's certainly has some truth to it. On the other hand, there weren't hat
many attemps to find paid consultancy on the mailing list so far ...


Greater adoption will be achieved only through time, IMHO;


Do great things (with Qooxdoo) and talk about them ...


jQuery has better adoption just because it's not used for the same things,
and a lot more people need some extra JS on a mostly server based web
system than a full blown OO JS library for a RIA.


Exactly ...


The only thing I wish for Qx is faster development,


As we heard a couple of times from 1&1 developers, their priority (and
rightly so) is determined by who ffeds them. Therefore my suggestion (see
other thread) to setup somw alternate means for getting things done (calling
this a "tax" is just completely misunderstanding the intention).


faster bug fixing.


This I can understand, but the same stated above applis here. But also note,
that (almost?) all weekly reports on the Qooxdoo home page (yet another
great and very much community-oriented effort) provide a link to the list of
bugs fixed during the last week.


Especially with bugs that have patches.


I'd guess this is an oversight ...


There is one bug on the
bugzilla that has a patch and is absolutely essential for us, but it
is still not applied upstream. But hey, man power is limited.



The build system is also a bit weird at times but for a newcomer,
everything works out of the box, so I dont really think there needs some
improvement there.


I think it's not always obvious (to me) if I want something else than the
out of the box (like profiling) ...  but then, usually help (thron) is just
an eMail away ...

Cheers,
Fritz

--
Oetiker+Partner AG  tel: +41 62 775 99 03 (direct)
Fritz Zaucker+41 62 775 99 00 (switch board)
Aarweg 15+41 79 675 06 30 (mobile)
CH-4600 Olten   fax: +41 62 775 99 05
Schweiz web: www.oetiker.ch--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing
http://p.sf.net/sfu/novell-sfdev2dev
___
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Re: [qooxdoo-devel] (off topic?) Qooxdoo's ecossystem question

2010-09-13 Thread Stefan Andersson


I want the tone of this discussion changes into the more positive direction.

Remember guys that there are language barriers from both sides.

Remember that if someone from the community has something to say it is not an 
act of evil. Instead it is an act of interest.

Please, be a little more patient with all ideas in all directions, even though 
it turns out to not be as beneficial as wished.

Diversity increases quality. Yes-sayers and silence will decrease interest of 
the community. A lively discussion is good in all means.

Unfortunately, as many think, money controls many of our actions and interests, 
so is the core team controlled by the interests and resources of 1&1. We are 
all limited in some aspect. Opening up the project will, under controlled 
conditions, enrichen the qooxdoo framework. Don't be afraid of that!

Let us instead discuss who can contribute with what! How many hours, how much 
money, how much consultancy etc etc to deliver more to the community. Is there 
an interest of this?

As I said in a previous posting, we are interested to put dedicated work 
resource(s), but as usual under certain conditions, increased openness, access 
to the delivery channel etc.

Is 1&1 interested to discuss this?

Stefan
  --
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing
http://p.sf.net/sfu/novell-sfdev2dev
___
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Re: [qooxdoo-devel] (off topic?) Qooxdoo's ecossystem question

2010-09-13 Thread Greg Beaver

 Hi,

As a new user to qooxdoo, perhaps my perspective could be useful. 
Ignore if not.

On 9/13/10 11:16 AM, Jean-Baptiste BRIAUD -- Novlog wrote:
> On 13 sept. 2010, at 18:07, thron7 wrote:
>
>>
>> On 09/13/2010 05:43 PM, Jean-Baptiste BRIAUD -- Novlog wrote:
>>> Thomas,
>>>
>>> You got wrong feeling.
>> Then what is it actually that you want? I understand you want a greater
>> recognition of qooxdoo in the French IT market. But how do you want that
>> to happen?
>>
> Thomas,
>
> we already discussed that s many time : make qooxdoo simpler to use for 
> new people :
> * python build optional rather than mandatory like now
I chose qooxdoo because of this!  The ability to get a fully compiled
(and super-fast) version without any extra work beyond a 1-liner
command-line thing is a huge plus.  The ability to detect missing
dependencies is another big thing for me.
> * qooxdoo in one big js file to download
this would not appeal to me whatsoever.  However, having the entire app
in a single .js file is *very* appealing (again going back to the build
stage).
> * better default theme
I do think qooxdoo would benefit from having a few more themes. 
Hopefully the dark theme will be good enough to promote from contrib to
core theme? :)  Ultimately, this isn't a showstopper for me.  (By the
way, I'm dying for a qxet theme release compatible with 1.2 *poke*
*poke*) :)

A bigger turn-off for me is the visual look of qooxdoo.org.  Compare to
the more popular frameworks' websites, and you'll see what I mean.  The
front door needs to prettier or most people will assume that the
framework sucks and move on to the next one.  For me, this was not a
showstopper, but I found qooxdoo because of a wikipedia article
comparing frameworks benchmarked it (0.8 version) as quite fast relative
to the others, and I was surprised considering I had never even heard of
it before.  Might be good to poke the author of that article to re-run
benches with 1.2.  I found the article by googling "javascript framework."

Greg

--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing
http://p.sf.net/sfu/novell-sfdev2dev
___
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Re: [qooxdoo-devel] (off topic?) Qooxdoo's ecossystem question

2010-09-13 Thread Tobias Oetiker

Stefan,

Today Stefan Volbers wrote:

> You may hire a C++ developer, who rewrites the build system for your
> needs in fast optimized code for your favourite platform (I assume
> you're a mac guy?).

Only a gut feeling, but I wonder if the build performance is realy
cpu bound or rather io-bound due to the many files qooxdoo has to
touch ... even with the cache ... or to put it differently there
may well be low hanging fruit to pick in the generator without
major rewriting if one puts a profiler to work ... (only guessing,
maybe thomas has done that already).

cheers
tobi

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
http://it.oetiker.ch [email protected] ++41 62 775 9902 / sb: -9900

--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing
http://p.sf.net/sfu/novell-sfdev2dev
___
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Re: [qooxdoo-devel] (off topic?) Qooxdoo's ecossystem question

2010-09-13 Thread thron7

> The only thing I wish for Qx is faster development, faster bugfixing.
> Especially with bugs that have patches. There is one bug on the
> bugzilla that has a patch and is absolutely essential for us, but it
> is still not applied upstream.

Which one is that?




--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing
http://p.sf.net/sfu/novell-sfdev2dev
___
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Re: [qooxdoo-devel] (off topic?) Qooxdoo's ecossystem question

2010-09-13 Thread Jean-Noël Rivasseau

Hello, just want to chime in.

I disagre with Jean-Baptiste about what needs to be done to trigger
greater adoption. Personally I think Python is a great choice for a
build system and I had no problems at all with this as a newcomer to
Qx. There are btw probably more companies in France using Qx that what
you may think (we are one of such companies), for a simple reason that
was already outlined: from a technical perspective, Qx rocks.

I think that's actually one of the reason that it's hard to find paid
consultancy on Qx: the framework is so good, and the support on the ML
is so good, who needs to pay a consultant ? ;)

Greater adoption will be achieved only through time, IMHO; jQuery has
better adoption just because it's not used for the same things, and a
lot more people need some extra JS on a mostly server based web system
than a full blown OO JS library for a RIA. Qx is better compared to
GWT (also a great library, btw) and GWT is more known because Google
has probably 1000 times the marketing power 1&1 has on the development
community (since Google produces an incredible amount of good stuff
for developers).
But if you compare for example Qx to Zapatec (also a JS RIA commercial
library - I used it in my previous company, it's expensive and a total
piece of crap), I am not sure Zapatec is more known than Qx.

The only thing I wish for Qx is faster development, faster bugfixing.
Especially with bugs that have patches. There is one bug on the
bugzilla that has a patch and is absolutely essential for us, but it
is still not applied upstream. But hey, man power is limited. The
build system is also a bit weird at times but for a newcomer,
everything works out of the box, so I dont really think there needs
some improvement there.

Cheers

Jean-Noel

On Mon, Sep 13, 2010 at 6:31 PM, thron7  wrote:
>
>
>>> I think projects also can grow too fast (meaning not as
>>> carefully designed/tested/etc).
>>
>> Growing too fast ? Are you serious ? That's not current qooxdoo problem !
>> You may have information I don't have, but according to me, qooxdoo is not 
>> growing fast enough.
>
> I think there are different issues:
>
> (a) A greater market recognition of qooxdoo, e.g. in the French market,
> so that you find it easier to get acceptance to chose qooxdoo for a
> customer project.
> (b) A greater qooxdoo user community.
>
> (b) might derive from (a), but they are still two separate issues.
>
> In case of (b), I'm re-stating what I have said before, and what is in
> line with Fritz' remark: We're on the brink of what we can handle
> manpower-wise. If e.g. the mailing list traffic would grow by, say, 30%
> and we would still try to provide the same level of support there, that
> might mean we had to entirely stop implementing new features in qooxdoo!
> Or cut down on testing. Or cut down dramatically on documentation. Or
> cut down on support otherwise. Just consider that.
>
> T.
>
> --
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing
> http://p.sf.net/sfu/novell-sfdev2dev
> ___
> qooxdoo-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>

-- 
Jean-Noël Rivasseau
Directeur
(1) 778 786 3460 / (33) 01 82 88 05 26
Kameleoon - morphing the web
http://www.kameleoon.com/

--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing
http://p.sf.net/sfu/novell-sfdev2dev
___
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Re: [qooxdoo-devel] (off topic?) Qooxdoo's ecossystem question

2010-09-13 Thread Jean-Baptiste BRIAUD -- Novlog


On 13 sept. 2010, at 18:47, Stefan Volbers wrote:

> Hi Jean-Baptiste,
> 
> if I may intercept in this discussion:
> 
Sure, you're welcome !

> I don't believe that qooxdoo'd get a better 'market share' if the python 
> build system'd disappear.
Optional rather than mandatory like now. That's all I would like.
I don't want the build to disappear.
How would we have the optimized version then ?
> You may not know that prior to qooxdoo 0.8 (or was it 0.7?) the build 
> system relied on 'make' instead of python, which was a disadvantage for 
> the windows platform, as one had to make use of cygwin to get access to 
> gnu make asf.
I was thinking about a version of qooxdoo that doesn't need build at all.
Make is not a good choice for qooxdoo, as you said, its a problem for Windows.
Only multiplateform should be OK.
Python is fine as long as there is a way for newcomers to avoid any build at 
all.

Download one js big file, preoptimized as mush as possible, and play with 
qooxdoo.
No need for Python, no need for a build.

Now after few months, one can without changing a line of code switch to qooxdoo 
with a build and the same code will run more quickly.
Isn't that great ? 

*** No constraint to start and the power just when you need it. ***

Unfortunately, you currently have to bother with python toolchain even before 
you know qooxdoo is cool.
That's one big reason that, I think, prevent a better qooxdoo adoption.

> 
> I cannot tell whether qooxdoo's adoption significantly increased since 
> switching to python (or even dropped). In fact, I don't really care, as 
> I can see the advantage of using qooxdoo, and myself, I am gonna adopt 
> the build system anyway.
> 
> Regarding the discussion so far:
> You claim that qooxdoo has bad adoption since it makes use of a python 
> build system;
no.
I think qooxdoo would have better adoption with an optional build (python or 
not).

> also you claim the build system is too slow for your work 
> flow.
That's true for us but it is another discussion since "we are special".
Even if I'm French, I hope I'm not arrogant enough to ask the community to do 
like us ;-)
To be honest, there is a link : that qooxdoo big file would be what we want to 
speed up the overall thing.





--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing
http://p.sf.net/sfu/novell-sfdev2dev
___
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Re: [qooxdoo-devel] (off topic?) Qooxdoo's ecossystem question

2010-09-13 Thread Stefan Volbers

Hi Jean-Baptiste,

if I may intercept in this discussion:

I don't believe that qooxdoo'd get a better 'market share' if the python 
build system'd disappear.
You may not know that prior to qooxdoo 0.8 (or was it 0.7?) the build 
system relied on 'make' instead of python, which was a disadvantage for 
the windows platform, as one had to make use of cygwin to get access to 
gnu make asf.

I cannot tell whether qooxdoo's adoption significantly increased since 
switching to python (or even dropped). In fact, I don't really care, as 
I can see the advantage of using qooxdoo, and myself, I am gonna adopt 
the build system anyway.

Regarding the discussion so far:
You claim that qooxdoo has bad adoption since it makes use of a python 
build system; also you claim the build system is too slow for your work 
flow. Because of the bad adoption, you cannot hire a qooxdoo developer 
in France.

I know a simple solution for your problems:
You may hire a C++ developer, who rewrites the build system for your 
needs in fast optimized code for your favourite platform (I assume 
you're a mac guy?).
Your builds will never be slow again, *and* you might open 
source-contrib the code for the rewritten build, so that an ecosystem of 
optimized platform-dependent can grow.
I could even imagine Thomas might help you in that task (as 1&1 would 
profit from a faster build solution too), if he finds time to.
This would consequently lead to platform-dependent sdk downloads, but... 
who cares? Such stuff could easily documented.
Only problem I see is the consequent need to support different build 
executables, so here the community would have to jump in.

What do you think?

Greetings
Stefan

On 13.09.2010 18:16, Jean-Baptiste BRIAUD -- Novlog wrote:
>
> On 13 sept. 2010, at 18:07, thron7 wrote:
>
>>
>>
>> On 09/13/2010 05:43 PM, Jean-Baptiste BRIAUD -- Novlog wrote:
>>> Thomas,
>>>
>>> You got wrong feeling.
>>
>> Then what is it actually that you want? I understand you want a greater
>> recognition of qooxdoo in the French IT market. But how do you want that
>> to happen?
>>
>
> Thomas,
>
> we already discussed that s many time : make qooxdoo simpler to use for 
> new people :
> * python build optional rather than mandatory like now
> * qooxdoo in one big js file to download
> * better default theme
> nothing more and as you see, nothing crazy like tv show.
> I think there is still some misunderstanding but I also understand it is not 
> a shared vision, that's fair enough.
> Do what you think is good for qooxdoo with your team.
> I'll focused only on technical things on that mailling list.
> I'm sorry for all that noise.
>

--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing
http://p.sf.net/sfu/novell-sfdev2dev
___
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Re: [qooxdoo-devel] (off topic?) Qooxdoo's ecossystem question

2010-09-13 Thread Jean-Baptiste BRIAUD -- Novlog


On 13 sept. 2010, at 18:31, thron7 wrote:

> 
> 
>>> I think projects also can grow too fast (meaning not as
>>> carefully designed/tested/etc).
>> 
>> Growing too fast ? Are you serious ? That's not current qooxdoo problem !
>> You may have information I don't have, but according to me, qooxdoo is not 
>> growing fast enough.
> 
> I think there are different issues:
> 
> (a) A greater market recognition of qooxdoo, e.g. in the French market,
> so that you find it easier to get acceptance to chose qooxdoo for a
> customer project.
> (b) A greater qooxdoo user community.
> 
> (b) might derive from (a), but they are still two separate issues.
> 
a derive from b !

> In case of (b), I'm re-stating what I have said before, and what is in
> line with Fritz' remark: We're on the brink of what we can handle
> manpower-wise. If e.g. the mailing list traffic would grow by, say, 30%
> and we would still try to provide the same level of support there, that
> might mean we had to entirely stop implementing new features in qooxdoo!
> Or cut down on testing. Or cut down dramatically on documentation. Or
> cut down on support otherwise. Just consider that.
> 

That's nice problems, the consequence of success. This would be so good.
I wish you to face that problem as soon as possible.
In fact, you forgot one data in your equation : more people = more help.
More people = more contrib => greater ecosystem => 1&1 core team can focus on 
new features.
Community will not accept the team loose too much time with support while 
waiting for features.
You are not alone in 1&1 team.
Don't be afraid of qooxdoo grow !

> T.
> 
> --
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing
> http://p.sf.net/sfu/novell-sfdev2dev
> ___
> qooxdoo-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel


--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing
http://p.sf.net/sfu/novell-sfdev2dev
___
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Re: [qooxdoo-devel] (off topic?) Qooxdoo's ecossystem question

2010-09-13 Thread thron7



>> I think projects also can grow too fast (meaning not as
>> carefully designed/tested/etc).
> 
> Growing too fast ? Are you serious ? That's not current qooxdoo problem !
> You may have information I don't have, but according to me, qooxdoo is not 
> growing fast enough.

I think there are different issues:

(a) A greater market recognition of qooxdoo, e.g. in the French market,
so that you find it easier to get acceptance to chose qooxdoo for a
customer project.
(b) A greater qooxdoo user community.

(b) might derive from (a), but they are still two separate issues.

In case of (b), I'm re-stating what I have said before, and what is in
line with Fritz' remark: We're on the brink of what we can handle
manpower-wise. If e.g. the mailing list traffic would grow by, say, 30%
and we would still try to provide the same level of support there, that
might mean we had to entirely stop implementing new features in qooxdoo!
Or cut down on testing. Or cut down dramatically on documentation. Or
cut down on support otherwise. Just consider that.

T.

--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing
http://p.sf.net/sfu/novell-sfdev2dev
___
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Re: [qooxdoo-devel] (off topic?) Qooxdoo's ecossystem question

2010-09-13 Thread Jean-Baptiste BRIAUD -- Novlog

On 13 sept. 2010, at 18:07, thron7 wrote:

> 
> 
> On 09/13/2010 05:43 PM, Jean-Baptiste BRIAUD -- Novlog wrote:
>> Thomas,
>> 
>> You got wrong feeling.
> 
> Then what is it actually that you want? I understand you want a greater
> recognition of qooxdoo in the French IT market. But how do you want that
> to happen?
> 

Thomas,

we already discussed that s many time : make qooxdoo simpler to use for new 
people :
* python build optional rather than mandatory like now
* qooxdoo in one big js file to download
* better default theme
nothing more and as you see, nothing crazy like tv show.
I think there is still some misunderstanding but I also understand it is not a 
shared vision, that's fair enough.
Do what you think is good for qooxdoo with your team.
I'll focused only on technical things on that mailling list.
I'm sorry for all that noise.

> T.
> 
>> 
>> JBB.
>> 
>> On 13 sept. 2010, at 17:19, thron7 wrote:
>> 
>>> Jean-Baptiste,
>>> 
>>> whenever I read your posts regarding this topic, I get the feeling that
>>> what you want is that somebody else (e.g. the qooxdoo core team and/or
>>> 1&1) will run an intense and largely successful image campaign for
>>> qooxdoo in France, including setting up promotional material in French,
>>> posting ads in French TV and magazines, and organizing exclusive
>>> qooxdoo-centric conferences for decision makers in Paris.
>>> 
>>> But I don't think this will happen.
>>> 
>>> T.
>>> 
>>> On 09/13/2010 04:12 PM, Jean-Baptiste BRIAUD -- Novlog wrote:
 Hi Fritz,

 Yes, why not for a longer perspective but at that time we needed quick and 
 local help.
 We couldn't afford the extra cost of travel/hotel for the consultancy and 
 didn't wanted to have remote help.

 There are also lots of other reasons why a local ecosystem is important : 
 people get accustomed to qooxdoo, they heard of it before I talk about it, 
 ...
 With existing ecosystem, qooxdoo become a choice, otherwise, people don't 
 want to consider that option because they don't have that ecosystem for 
 themselves.
 This is typical to start using a pump : you need water first to start the 
 pump but you have bought the pump because you don't have water.
 Company here sometimes don't choose qooxdoo because there is no qooxdoo 
 ecosystem and that's just increase the lack of qooxdoo ecosystem in France.
 Other apparent competitor already have that critical mass and that's why 
 it is important for qooxdoo to have it out of Germany/Switzerland.
 I said "apparent" competitor because we all know why it is not true on a 
 technical point of view but that's not the only point of view, 
 unfortunately for Qooxdoo.

 Thank you for you reply.  Unfortunately the lack of other reply on that 
 ecosystem question show how it is not perceive as a problem and why it 
 won't change quickly I'm afraid.
 So, how will qooxdoo get that critical mass outside Germany/Switzerland ?
 We already twit, comments on some blog like ajaxian, contribute, ... and 
 still there are only 2 known companies in France (I hope there are a 
 little more than we know).
 This big question for me is How can qooxdoo think it will compete to other 
 "web framework" with lots of "acquired" companies ?
 By compete, I mean be known, become a possible choice. How could you 
 choose something you just don't know it exists ?
 I know several really good products that just die to be the best on a 
 technical point of view, maybe they thought only technical point of view 
 counted, anyway, they are no more there to explain us their choice ...

 We don't have to loose momentum, this is as important as being the best 
 technical tools.
 I'm not sure if all that kind of things are just "bad ideas" or if only 
 few of us care about it or if I'm so unclear that nobody understand why so 
 much noise for nothing or ... something else ?

 ... and please, don't tell me I can use other product if I'm not 
 satisfied. This would be a way to escape the problem and BTW I am really 
 globally satisfied, I would not care about a product I'm not satisfied 
 with.
 This is because we plan to use qooxdoo on a long term perspective that I 
 care so much.

 On 13 sept. 2010, at 15:43, Fritz Zaucker wrote:

> Hi Jean-Baptiste,
> 
> On Fri, 10 Sep 2010, Jean-Baptiste BRIAUD -- Novlog wrote:
> 
>> On 10 sept. 2010, at 04:55, Leandro Santiago wrote:
>> 
>>> (IMHO) In this case, is essential to create an ecossystem around qooxdoo
>> 
>> Yes, fully agree. In France, qooxdoo is mainly unknown. I was not able to
>> get paid consultancy !
> 
> how about looking across the border? Many places in Switzerland are
> closer to you than some places in France ...
> 
> Cheers,
> Fritz
> 
> -- 
> Oetiker+Pa

Re: [qooxdoo-devel] (off topic?) Qooxdoo's ecossystem question

2010-09-13 Thread thron7



On 09/13/2010 05:43 PM, Jean-Baptiste BRIAUD -- Novlog wrote:
> Thomas,
> 
> You got wrong feeling.

Then what is it actually that you want? I understand you want a greater
recognition of qooxdoo in the French IT market. But how do you want that
to happen?

T.

> 
> JBB.
> 
> On 13 sept. 2010, at 17:19, thron7 wrote:
> 
>> Jean-Baptiste,
>>
>> whenever I read your posts regarding this topic, I get the feeling that
>> what you want is that somebody else (e.g. the qooxdoo core team and/or
>> 1&1) will run an intense and largely successful image campaign for
>> qooxdoo in France, including setting up promotional material in French,
>> posting ads in French TV and magazines, and organizing exclusive
>> qooxdoo-centric conferences for decision makers in Paris.
>>
>> But I don't think this will happen.
>>
>> T.
>>
>> On 09/13/2010 04:12 PM, Jean-Baptiste BRIAUD -- Novlog wrote:
>>> Hi Fritz,
>>>
>>> Yes, why not for a longer perspective but at that time we needed quick and 
>>> local help.
>>> We couldn't afford the extra cost of travel/hotel for the consultancy and 
>>> didn't wanted to have remote help.
>>>
>>> There are also lots of other reasons why a local ecosystem is important : 
>>> people get accustomed to qooxdoo, they heard of it before I talk about it, 
>>> ...
>>> With existing ecosystem, qooxdoo become a choice, otherwise, people don't 
>>> want to consider that option because they don't have that ecosystem for 
>>> themselves.
>>> This is typical to start using a pump : you need water first to start the 
>>> pump but you have bought the pump because you don't have water.
>>> Company here sometimes don't choose qooxdoo because there is no qooxdoo 
>>> ecosystem and that's just increase the lack of qooxdoo ecosystem in France.
>>> Other apparent competitor already have that critical mass and that's why it 
>>> is important for qooxdoo to have it out of Germany/Switzerland.
>>> I said "apparent" competitor because we all know why it is not true on a 
>>> technical point of view but that's not the only point of view, 
>>> unfortunately for Qooxdoo.
>>>
>>> Thank you for you reply.  Unfortunately the lack of other reply on that 
>>> ecosystem question show how it is not perceive as a problem and why it 
>>> won't change quickly I'm afraid.
>>> So, how will qooxdoo get that critical mass outside Germany/Switzerland ?
>>> We already twit, comments on some blog like ajaxian, contribute, ... and 
>>> still there are only 2 known companies in France (I hope there are a little 
>>> more than we know).
>>> This big question for me is How can qooxdoo think it will compete to other 
>>> "web framework" with lots of "acquired" companies ?
>>> By compete, I mean be known, become a possible choice. How could you choose 
>>> something you just don't know it exists ?
>>> I know several really good products that just die to be the best on a 
>>> technical point of view, maybe they thought only technical point of view 
>>> counted, anyway, they are no more there to explain us their choice ...
>>>
>>> We don't have to loose momentum, this is as important as being the best 
>>> technical tools.
>>> I'm not sure if all that kind of things are just "bad ideas" or if only few 
>>> of us care about it or if I'm so unclear that nobody understand why so much 
>>> noise for nothing or ... something else ?
>>>
>>> ... and please, don't tell me I can use other product if I'm not satisfied. 
>>> This would be a way to escape the problem and BTW I am really globally 
>>> satisfied, I would not care about a product I'm not satisfied with.
>>> This is because we plan to use qooxdoo on a long term perspective that I 
>>> care so much.
>>>
>>> On 13 sept. 2010, at 15:43, Fritz Zaucker wrote:
>>>
 Hi Jean-Baptiste,

 On Fri, 10 Sep 2010, Jean-Baptiste BRIAUD -- Novlog wrote:

> On 10 sept. 2010, at 04:55, Leandro Santiago wrote:
>
>> (IMHO) In this case, is essential to create an ecossystem around qooxdoo
>
> Yes, fully agree. In France, qooxdoo is mainly unknown. I was not able to
> get paid consultancy !

 how about looking across the border? Many places in Switzerland are
 closer to you than some places in France ...

 Cheers,
 Fritz

 -- 
 Oetiker+Partner AG tel: +41 62 775 9903 (direct)
 Fritz Zaucker+41 62 775 9900 (switch board)
 Aarweg 15+41 79 675 0630 (mobile)
 CH-4600 Olten   fax: +41 62 775 9905
 Schweiz web: www.oetiker.ch

 --
 Start uncovering the many advantages of virtual appliances
 and start using them to simplify application deployment and
 accelerate your shift to cloud computing
 http://p.sf.net/sfu/novell-sfdev2dev
 ___
 qooxdoo-devel mailing list
 [email protected]

Re: [qooxdoo-devel] (off topic?) Qooxdoo's ecossystem question

2010-09-13 Thread Jean-Baptiste BRIAUD -- Novlog

Short version : I won't discuss that anymore and I'll focused only on technical 
discussion on that mailing list.
Sorry for the noise.

On 13 sept. 2010, at 16:47, Fritz Zaucker wrote:

> Hi Jean-Baptiste,
> 
> On Mon, 13 Sep 2010, Jean-Baptiste BRIAUD -- Novlog wrote:
> 
>> Yes, why not for a longer perspective but at that time we needed quick and
>> local help. We couldn't afford the extra cost of travel/hotel for the
>> consultancy
> 
> so that would mean you needed a company in or around Paris. Well, I guess
> from a Parisienne perspective this is equivalent to "no paid QX consultant
> in France" ... ;-)
> 

I don't understand your point at all. How do you create a link between our very 
common will to have local help and the fact it would be like not paying the 
consultancy ?
It is very common to have paid consultancy between local company, so no travel 
is involve.
It is still paid consultancy.

>> and didn't wanted to have remote help.
> 
> Some people might even consider to be put up in somebodies house for an
> interesting project ...

Again, what are you trying to say ? I'm sorry but I don't understand.

> 
>> There are also lots of other reasons why a local ecosystem is important :
>> people get accustomed to qooxdoo, they heard of it before I talk about it,
>> ... With existing ecosystem, qooxdoo become a choice, otherwise, people
>> don't want to consider that option because they don't have that ecosystem
>> for themselves. This is typical to start using a pump : you need water
>> first to start the pump but you have bought the pump because you don't
>> have water. Company here sometimes don't choose qooxdoo because there is
>> no qooxdoo ecosystem and that's just increase the lack of qooxdoo
>> ecosystem in France. Other apparent competitor already have that critical
>> mass and that's why it is important for qooxdoo to have it out of
>> Germany/Switzerland. I said "apparent" competitor because we all know why
>> it is not true on a technical point of view but that's not the only point
>> of view, unfortunately for Qooxdoo.
>> 
>> Thank you for you reply.  Unfortunately the lack of other reply on that
>> ecosystem question show how it is not perceive as a problem and why it
>> won't change quickly I'm afraid. So, how will qooxdoo get that critical
>> mass outside Germany/Switzerland ? We already twit, comments on some blog
>> like ajaxian, contribute, ... and still there are only 2 known companies
>> in France (I hope there are a little more than we know). This big question
>> for me is How can qooxdoo think it will compete to other "web framework"
>> with lots of "acquired" companies ? By compete, I mean be known, become a
>> possible choice. How could you choose something you just don't know it
>> exists ? I know several really good products that just die to be the best
>> on a technical point of view, maybe they thought only technical point of
>> view counted, anyway, they are no more there to explain us their choice
>> ...
>> 
>> We don't have to loose momentum, this is as important as being the best
>> technical tools. I'm not sure if all that kind of things are just "bad
>> ideas" or if only few of us care about it or if I'm so unclear that nobody
>> understand why so much noise for nothing or ... something else ?
> 
> I think I do understand your point.

Cool, so it make sense ...

> On the other side, we were/are in the
> same situation when Tobi "discovered" Qooxdoo and we just decided to go for
> it (as you did).
> So far we have more than enough projects that allow us to
> use Qooxdoo (and make some contributions to it on the way, not the least
> giving talks/tutorials at various conferences to spread the word).
> 

This is cool. So what ?

> I am NOT sure that everything would be better if Qooxdoo was being picked up
> a lot faster.

Everything ? Of course not  and it was not my point !
It would "only" be, relatively speaking, better, this is still ... very 
important.

> I think projects also can grow too fast (meaning not as
> carefully designed/tested/etc).

Growing too fast ? Are you serious ? That's not current qooxdoo problem !
You may have information I don't have, but according to me, qooxdoo is not 
growing fast enough.

> 
>> ... and please, don't tell me I can use other product if I'm not satisfied.
> 
> I didn't intend to.

That sentence was not here for you but to ensure I won't get that kind of quick 
non-answer if any ...

> 
>> This would be a way to escape the problem and BTW I am really globally
>> satisfied, I would not care about a product I'm not satisfied with.
> 
> Indeed.
> 
>> This is because we plan to use qooxdoo on a long term perspective that I
>> care so much.
> 
> So do we and I think at the moment the best we can do is to implement great
> applications with it and have the rumor spread by word of mouth.
> 
> And perhaps to make things a bit faster, provided that there IS a market for
> it (meaning some of the people requesting a lot also providing s

Re: [qooxdoo-devel] (off topic?) Qooxdoo's ecossystem question

2010-09-13 Thread Jean-Baptiste BRIAUD -- Novlog

Thomas,

You got wrong feeling.

JBB.

On 13 sept. 2010, at 17:19, thron7 wrote:

> Jean-Baptiste,
> 
> whenever I read your posts regarding this topic, I get the feeling that
> what you want is that somebody else (e.g. the qooxdoo core team and/or
> 1&1) will run an intense and largely successful image campaign for
> qooxdoo in France, including setting up promotional material in French,
> posting ads in French TV and magazines, and organizing exclusive
> qooxdoo-centric conferences for decision makers in Paris.
> 
> But I don't think this will happen.
> 
> T.
> 
> On 09/13/2010 04:12 PM, Jean-Baptiste BRIAUD -- Novlog wrote:
>> Hi Fritz,
>> 
>> Yes, why not for a longer perspective but at that time we needed quick and 
>> local help.
>> We couldn't afford the extra cost of travel/hotel for the consultancy and 
>> didn't wanted to have remote help.
>> 
>> There are also lots of other reasons why a local ecosystem is important : 
>> people get accustomed to qooxdoo, they heard of it before I talk about it, 
>> ...
>> With existing ecosystem, qooxdoo become a choice, otherwise, people don't 
>> want to consider that option because they don't have that ecosystem for 
>> themselves.
>> This is typical to start using a pump : you need water first to start the 
>> pump but you have bought the pump because you don't have water.
>> Company here sometimes don't choose qooxdoo because there is no qooxdoo 
>> ecosystem and that's just increase the lack of qooxdoo ecosystem in France.
>> Other apparent competitor already have that critical mass and that's why it 
>> is important for qooxdoo to have it out of Germany/Switzerland.
>> I said "apparent" competitor because we all know why it is not true on a 
>> technical point of view but that's not the only point of view, unfortunately 
>> for Qooxdoo.
>> 
>> Thank you for you reply.  Unfortunately the lack of other reply on that 
>> ecosystem question show how it is not perceive as a problem and why it won't 
>> change quickly I'm afraid.
>> So, how will qooxdoo get that critical mass outside Germany/Switzerland ?
>> We already twit, comments on some blog like ajaxian, contribute, ... and 
>> still there are only 2 known companies in France (I hope there are a little 
>> more than we know).
>> This big question for me is How can qooxdoo think it will compete to other 
>> "web framework" with lots of "acquired" companies ?
>> By compete, I mean be known, become a possible choice. How could you choose 
>> something you just don't know it exists ?
>> I know several really good products that just die to be the best on a 
>> technical point of view, maybe they thought only technical point of view 
>> counted, anyway, they are no more there to explain us their choice ...
>> 
>> We don't have to loose momentum, this is as important as being the best 
>> technical tools.
>> I'm not sure if all that kind of things are just "bad ideas" or if only few 
>> of us care about it or if I'm so unclear that nobody understand why so much 
>> noise for nothing or ... something else ?
>> 
>> ... and please, don't tell me I can use other product if I'm not satisfied. 
>> This would be a way to escape the problem and BTW I am really globally 
>> satisfied, I would not care about a product I'm not satisfied with.
>> This is because we plan to use qooxdoo on a long term perspective that I 
>> care so much.
>> 
>> On 13 sept. 2010, at 15:43, Fritz Zaucker wrote:
>> 
>>> Hi Jean-Baptiste,
>>> 
>>> On Fri, 10 Sep 2010, Jean-Baptiste BRIAUD -- Novlog wrote:
>>> 
 On 10 sept. 2010, at 04:55, Leandro Santiago wrote:
 
> (IMHO) In this case, is essential to create an ecossystem around qooxdoo
 
 Yes, fully agree. In France, qooxdoo is mainly unknown. I was not able to
 get paid consultancy !
>>> 
>>> how about looking across the border? Many places in Switzerland are
>>> closer to you than some places in France ...
>>> 
>>> Cheers,
>>> Fritz
>>> 
>>> -- 
>>> Oetiker+Partner AG  tel: +41 62 775 9903 (direct)
>>> Fritz Zaucker+41 62 775 9900 (switch board)
>>> Aarweg 15+41 79 675 0630 (mobile)
>>> CH-4600 Olten   fax: +41 62 775 9905
>>> Schweiz web: www.oetiker.ch
>>> 
>>> --
>>> Start uncovering the many advantages of virtual appliances
>>> and start using them to simplify application deployment and
>>> accelerate your shift to cloud computing
>>> http://p.sf.net/sfu/novell-sfdev2dev
>>> ___
>>> qooxdoo-devel mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>> 
>> 
>> --
>> Start uncovering the many advantages of virtual appliances
>> and start using them to simplify application deployment and
>> accelerate your shift to

Re: [qooxdoo-devel] (off topic?) Qooxdoo's ecossystem question

2010-09-13 Thread thron7

Jean-Baptiste,

whenever I read your posts regarding this topic, I get the feeling that
what you want is that somebody else (e.g. the qooxdoo core team and/or
1&1) will run an intense and largely successful image campaign for
qooxdoo in France, including setting up promotional material in French,
posting ads in French TV and magazines, and organizing exclusive
qooxdoo-centric conferences for decision makers in Paris.

But I don't think this will happen.

T.

On 09/13/2010 04:12 PM, Jean-Baptiste BRIAUD -- Novlog wrote:
> Hi Fritz,
> 
> Yes, why not for a longer perspective but at that time we needed quick and 
> local help.
> We couldn't afford the extra cost of travel/hotel for the consultancy and 
> didn't wanted to have remote help.
> 
> There are also lots of other reasons why a local ecosystem is important : 
> people get accustomed to qooxdoo, they heard of it before I talk about it, ...
> With existing ecosystem, qooxdoo become a choice, otherwise, people don't 
> want to consider that option because they don't have that ecosystem for 
> themselves.
> This is typical to start using a pump : you need water first to start the 
> pump but you have bought the pump because you don't have water.
> Company here sometimes don't choose qooxdoo because there is no qooxdoo 
> ecosystem and that's just increase the lack of qooxdoo ecosystem in France.
> Other apparent competitor already have that critical mass and that's why it 
> is important for qooxdoo to have it out of Germany/Switzerland.
> I said "apparent" competitor because we all know why it is not true on a 
> technical point of view but that's not the only point of view, unfortunately 
> for Qooxdoo.
> 
> Thank you for you reply.  Unfortunately the lack of other reply on that 
> ecosystem question show how it is not perceive as a problem and why it won't 
> change quickly I'm afraid.
> So, how will qooxdoo get that critical mass outside Germany/Switzerland ?
> We already twit, comments on some blog like ajaxian, contribute, ... and 
> still there are only 2 known companies in France (I hope there are a little 
> more than we know).
> This big question for me is How can qooxdoo think it will compete to other 
> "web framework" with lots of "acquired" companies ?
> By compete, I mean be known, become a possible choice. How could you choose 
> something you just don't know it exists ?
> I know several really good products that just die to be the best on a 
> technical point of view, maybe they thought only technical point of view 
> counted, anyway, they are no more there to explain us their choice ...
> 
> We don't have to loose momentum, this is as important as being the best 
> technical tools.
> I'm not sure if all that kind of things are just "bad ideas" or if only few 
> of us care about it or if I'm so unclear that nobody understand why so much 
> noise for nothing or ... something else ?
> 
> ... and please, don't tell me I can use other product if I'm not satisfied. 
> This would be a way to escape the problem and BTW I am really globally 
> satisfied, I would not care about a product I'm not satisfied with.
> This is because we plan to use qooxdoo on a long term perspective that I care 
> so much.
> 
> On 13 sept. 2010, at 15:43, Fritz Zaucker wrote:
> 
>> Hi Jean-Baptiste,
>>
>> On Fri, 10 Sep 2010, Jean-Baptiste BRIAUD -- Novlog wrote:
>>
>>> On 10 sept. 2010, at 04:55, Leandro Santiago wrote:
>>>
 (IMHO) In this case, is essential to create an ecossystem around qooxdoo
>>>
>>> Yes, fully agree. In France, qooxdoo is mainly unknown. I was not able to
>>> get paid consultancy !
>>
>> how about looking across the border? Many places in Switzerland are
>> closer to you than some places in France ...
>>
>> Cheers,
>> Fritz
>>
>> -- 
>> Oetiker+Partner AG   tel: +41 62 775 9903 (direct)
>> Fritz Zaucker+41 62 775 9900 (switch board)
>> Aarweg 15+41 79 675 0630 (mobile)
>> CH-4600 Olten   fax: +41 62 775 9905
>> Schweiz web: www.oetiker.ch
>>
>> --
>> Start uncovering the many advantages of virtual appliances
>> and start using them to simplify application deployment and
>> accelerate your shift to cloud computing
>> http://p.sf.net/sfu/novell-sfdev2dev
>> ___
>> qooxdoo-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
> 
> 
> --
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing
> http://p.sf.net/sfu/novell-sfdev2dev
> ___
> qooxdoo-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/

Re: [qooxdoo-devel] (off topic?) Qooxdoo's ecossystem question

2010-09-13 Thread Fritz Zaucker

Hi Jean-Baptiste,

On Mon, 13 Sep 2010, Jean-Baptiste BRIAUD -- Novlog wrote:

> Yes, why not for a longer perspective but at that time we needed quick and
> local help. We couldn't afford the extra cost of travel/hotel for the
> consultancy

so that would mean you needed a company in or around Paris. Well, I guess
from a Parisienne perspective this is equivalent to "no paid QX consultant
in France" ... ;-)

> and didn't wanted to have remote help.

Some people might even consider to be put up in somebodies house for an
interesting project ...

> There are also lots of other reasons why a local ecosystem is important :
> people get accustomed to qooxdoo, they heard of it before I talk about it,
> ... With existing ecosystem, qooxdoo become a choice, otherwise, people
> don't want to consider that option because they don't have that ecosystem
> for themselves. This is typical to start using a pump : you need water
> first to start the pump but you have bought the pump because you don't
> have water. Company here sometimes don't choose qooxdoo because there is
> no qooxdoo ecosystem and that's just increase the lack of qooxdoo
> ecosystem in France. Other apparent competitor already have that critical
> mass and that's why it is important for qooxdoo to have it out of
> Germany/Switzerland. I said "apparent" competitor because we all know why
> it is not true on a technical point of view but that's not the only point
> of view, unfortunately for Qooxdoo.
>
> Thank you for you reply.  Unfortunately the lack of other reply on that
> ecosystem question show how it is not perceive as a problem and why it
> won't change quickly I'm afraid. So, how will qooxdoo get that critical
> mass outside Germany/Switzerland ? We already twit, comments on some blog
> like ajaxian, contribute, ... and still there are only 2 known companies
> in France (I hope there are a little more than we know). This big question
> for me is How can qooxdoo think it will compete to other "web framework"
> with lots of "acquired" companies ? By compete, I mean be known, become a
> possible choice. How could you choose something you just don't know it
> exists ? I know several really good products that just die to be the best
> on a technical point of view, maybe they thought only technical point of
> view counted, anyway, they are no more there to explain us their choice
> ...
>
> We don't have to loose momentum, this is as important as being the best
> technical tools. I'm not sure if all that kind of things are just "bad
> ideas" or if only few of us care about it or if I'm so unclear that nobody
> understand why so much noise for nothing or ... something else ?

I think I do understand your point. On the other side, we were/are in the
same situation when Tobi "discovered" Qooxdoo and we just decided to go for
it (as you did). So far we have more than enough projects that allow us to
use Qooxdoo (and make some contributions to it on the way, not the least
giving talks/tutorials at various conferences to spread the word).

I am NOT sure that everything would be better if Qooxdoo was being picked up
a lot faster. I think projects also can grow too fast (meaning not as
carefully designed/tested/etc).

> ... and please, don't tell me I can use other product if I'm not satisfied.

I didn't intend to.

> This would be a way to escape the problem and BTW I am really globally
> satisfied, I would not care about a product I'm not satisfied with.

Indeed.

> This is because we plan to use qooxdoo on a long term perspective that I
> care so much.

So do we and I think at the moment the best we can do is to implement great
applications with it and have the rumor spread by word of mouth.

And perhaps to make things a bit faster, provided that there IS a market for
it (meaning some of the people requesting a lot also providing some
resources for it) and not just a lot of demand for "free beer ...".

Cheers,
Fritz

> On 13 sept. 2010, at 15:43, Fritz Zaucker wrote:
>
>> Hi Jean-Baptiste,
>>
>> On Fri, 10 Sep 2010, Jean-Baptiste BRIAUD -- Novlog wrote:
>>
>>> On 10 sept. 2010, at 04:55, Leandro Santiago wrote:
>>>
 (IMHO) In this case, is essential to create an ecossystem around qooxdoo
>>>
>>> Yes, fully agree. In France, qooxdoo is mainly unknown. I was not able to
>>> get paid consultancy !
>>
>> how about looking across the border? Many places in Switzerland are
>> closer to you than some places in France ...
>>
>> Cheers,
>> Fritz
>>
>> --
>> Oetiker+Partner AG   tel: +41 62 775 9903 (direct)
>> Fritz Zaucker+41 62 775 9900 (switch board)
>> Aarweg 15+41 79 675 0630 (mobile)
>> CH-4600 Olten   fax: +41 62 775 9905
>> Schweiz web: www.oetiker.ch
>>
>> --
>> Start uncovering the many advantages of virtual appliances
>> and start using them to simplify application deployment an

Re: [qooxdoo-devel] (off topic?) Qooxdoo's ecossystem question

2010-09-13 Thread Jean-Baptiste BRIAUD -- Novlog

Hi Fritz,

Yes, why not for a longer perspective but at that time we needed quick and 
local help.
We couldn't afford the extra cost of travel/hotel for the consultancy and 
didn't wanted to have remote help.

There are also lots of other reasons why a local ecosystem is important : 
people get accustomed to qooxdoo, they heard of it before I talk about it, ...
With existing ecosystem, qooxdoo become a choice, otherwise, people don't want 
to consider that option because they don't have that ecosystem for themselves.
This is typical to start using a pump : you need water first to start the pump 
but you have bought the pump because you don't have water.
Company here sometimes don't choose qooxdoo because there is no qooxdoo 
ecosystem and that's just increase the lack of qooxdoo ecosystem in France.
Other apparent competitor already have that critical mass and that's why it is 
important for qooxdoo to have it out of Germany/Switzerland.
I said "apparent" competitor because we all know why it is not true on a 
technical point of view but that's not the only point of view, unfortunately 
for Qooxdoo.

Thank you for you reply.  Unfortunately the lack of other reply on that 
ecosystem question show how it is not perceive as a problem and why it won't 
change quickly I'm afraid.
So, how will qooxdoo get that critical mass outside Germany/Switzerland ?
We already twit, comments on some blog like ajaxian, contribute, ... and still 
there are only 2 known companies in France (I hope there are a little more than 
we know).
This big question for me is How can qooxdoo think it will compete to other "web 
framework" with lots of "acquired" companies ?
By compete, I mean be known, become a possible choice. How could you choose 
something you just don't know it exists ?
I know several really good products that just die to be the best on a technical 
point of view, maybe they thought only technical point of view counted, anyway, 
they are no more there to explain us their choice ...

We don't have to loose momentum, this is as important as being the best 
technical tools.
I'm not sure if all that kind of things are just "bad ideas" or if only few of 
us care about it or if I'm so unclear that nobody understand why so much noise 
for nothing or ... something else ?

... and please, don't tell me I can use other product if I'm not satisfied. 
This would be a way to escape the problem and BTW I am really globally 
satisfied, I would not care about a product I'm not satisfied with.
This is because we plan to use qooxdoo on a long term perspective that I care 
so much.

On 13 sept. 2010, at 15:43, Fritz Zaucker wrote:

> Hi Jean-Baptiste,
> 
> On Fri, 10 Sep 2010, Jean-Baptiste BRIAUD -- Novlog wrote:
> 
>> On 10 sept. 2010, at 04:55, Leandro Santiago wrote:
>> 
>>> (IMHO) In this case, is essential to create an ecossystem around qooxdoo
>> 
>> Yes, fully agree. In France, qooxdoo is mainly unknown. I was not able to
>> get paid consultancy !
> 
> how about looking across the border? Many places in Switzerland are
> closer to you than some places in France ...
> 
> Cheers,
> Fritz
> 
> -- 
> Oetiker+Partner AGtel: +41 62 775 9903 (direct)
> Fritz Zaucker+41 62 775 9900 (switch board)
> Aarweg 15+41 79 675 0630 (mobile)
> CH-4600 Olten   fax: +41 62 775 9905
> Schweiz web: www.oetiker.ch
> 
> --
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing
> http://p.sf.net/sfu/novell-sfdev2dev
> ___
> qooxdoo-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing
http://p.sf.net/sfu/novell-sfdev2dev
___
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Re: [qooxdoo-devel] (off topic?) Qooxdoo's ecossystem question

2010-09-13 Thread Fritz Zaucker

Hi Jean-Baptiste,

On Fri, 10 Sep 2010, Jean-Baptiste BRIAUD -- Novlog wrote:

> On 10 sept. 2010, at 04:55, Leandro Santiago wrote:
>
>> (IMHO) In this case, is essential to create an ecossystem around qooxdoo
>
> Yes, fully agree. In France, qooxdoo is mainly unknown. I was not able to
> get paid consultancy !

how about looking across the border? Many places in Switzerland are
closer to you than some places in France ...

Cheers,
Fritz

-- 
Oetiker+Partner AG  tel: +41 62 775 9903 (direct)
Fritz Zaucker+41 62 775 9900 (switch board)
Aarweg 15+41 79 675 0630 (mobile)
CH-4600 Olten   fax: +41 62 775 9905
Schweiz web: www.oetiker.ch

--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing
http://p.sf.net/sfu/novell-sfdev2dev
___
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Re: [qooxdoo-devel] (off topic?) Qooxdoo's ecossystem question

2010-09-10 Thread thron7


> I have some dificulties to express in English (and to read too, so I
> haven't finished to read all replies), but I think that if was a big
> company behind qooxdoo development it could be improved.

Actually, that is the case. Only that in the case of qooxdoo, the
company, 1&1, is in a much larger business than with Sencha.

> 
> I'm sorry if I said something wrong.

Don't worry Leandro, it is not uncommon that a discussion evolves in
directions unforeseen :). You will not be held responsible :).

T.


--
Automate Storage Tiering Simply
Optimize IT performance and efficiency through flexible, powerful, 
automated storage tiering capabilities. View this brief to learn how
you can reduce costs and improve performance. 
http://p.sf.net/sfu/dell-sfdev2dev
___
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Re: [qooxdoo-devel] (off topic?) Qooxdoo's ecossystem question

2010-09-10 Thread Leandro Santiago

Yes, and it's growing... :-)

To all: thanks for your answers. When I started this discussion I just
would like to clarify some questions. I wouldn't want you say "Hey,
there is a guy in the other side of the world with many wishes. Let's
resolve his problem and make him happy?" :-)

But I think qooxdoo is a powerful project which can grow much more. I
really need to help, I'm learning qooxdoo to use it profissionally,
and when I have condition "support" it, with money (hey, I'm a student
and the money is low), code and spreading its existence.

But I'm seing some other projects like ExtJS (now Sencha) investing in
the ecossystem around their main product (the js framework): a mobile
framework, a designer tool, etc. But Sencha is a company and qooxdoo
isn't.

I have some dificulties to express in English (and to read too, so I
haven't finished to read all replies), but I think that if was a big
company behind qooxdoo development it could be improved.

I'm sorry if I said something wrong.

But I still think qooxdoo is amazing :-)

2010/9/10 Jean-Baptiste BRIAUD -- Novlog :
>
> qooxdoo IRC channel : #qooxdoo on irc.freenode.net
>
> But this channel is always quite empty. Right now there are only 7
> people there :-(
>
>
> Continue to get there anyway so it will grow, otherwise, if anyone get out
> because there is only 7, it will never reach critical mass :-)
>
> --
> Automate Storage Tiering Simply
> Optimize IT performance and efficiency through flexible, powerful,
> automated storage tiering capabilities. View this brief to learn how
> you can reduce costs and improve performance.
> http://p.sf.net/sfu/dell-sfdev2dev
> ___
> qooxdoo-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
>

--
Automate Storage Tiering Simply
Optimize IT performance and efficiency through flexible, powerful, 
automated storage tiering capabilities. View this brief to learn how
you can reduce costs and improve performance. 
http://p.sf.net/sfu/dell-sfdev2dev
___
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Re: [qooxdoo-devel] (off topic?) Qooxdoo's ecossystem question

2010-09-10 Thread Petr Kobalíček

Hi guys,

I agree with Jean.

I think that the qooxdoo needs similar architecture like all other JS
libraries. I'm experienced developer in many programming languages and
I hate to use qooxdoo generator. The reason I choose qooxdoo is very
simple - in few days I was able to build qooxdoo-all-in-one (in fact
the 0.7 version contained this so I just used the same idea for 0.8+).

So my advise to spread qooxdoo is "make it simple":

1. Download
2, Include js+resources
3. Run

jQuery was also mentioned here. Personally I think that architecture
of jQuery is bad, but it is so simple to include/use it in any
project. So many "web developers" and "SEO experts" can use it without
problems, because it just works and thanks to community there are
zillion of usable extensions.

In summary:
1. I think that qooxdoo integration should be simple like other libs;
2. Size of community is important (bug reports, contributions, maturity);
3. Look of GUI is important (not website, modern theme should be redesigned).

My two cents, repeated again and again;)

Best regards
Petr

--
Automate Storage Tiering Simply
Optimize IT performance and efficiency through flexible, powerful, 
automated storage tiering capabilities. View this brief to learn how
you can reduce costs and improve performance. 
http://p.sf.net/sfu/dell-sfdev2dev
___
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Re: [qooxdoo-devel] (off topic?) Qooxdoo's ecossystem question

2010-09-10 Thread Jean-Baptiste BRIAUD -- Novlog

>> 
>> qooxdoo IRC channel : #qooxdoo on irc.freenode.net
> But this channel is always quite empty. Right now there are only 7
> people there :-(
>> 

Continue to get there anyway so it will grow, otherwise, if anyone get out 
because there is only 7, it will never reach critical mass :-)

--
Automate Storage Tiering Simply
Optimize IT performance and efficiency through flexible, powerful, 
automated storage tiering capabilities. View this brief to learn how
you can reduce costs and improve performance. 
http://p.sf.net/sfu/dell-sfdev2dev___
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Re: [qooxdoo-devel] (off topic?) Qooxdoo's ecossystem question

2010-09-10 Thread Leandro Santiago

2010/9/10 Jean-Baptiste BRIAUD -- Novlog :
> Hi Leandro,
>
> On 10 sept. 2010, at 04:55, Leandro Santiago wrote:
>
>> Hello to all. (Sorry for my bad English, I'm Brazilian, I hope you
>> understand me, and yes, it's a long text :-))
>>
>> I'm a qooxdoo fan's, even I being a newbie :-)
>>
>
> Welcome !
>
>> I'm thinking in how qooxdoo is a great framework, but it isn't very
>> know. Many people use other frameworks for RIA,  like Flex (here in
>> Brazil it's very famous) or Silverlight and they usually spend a lot
>> of money with these tools and other things.
>>
>
> I agree.
>
>> Flex is know for the MXML dialect. Qooxdoo is incredible and there is
>> QxTransformer, which as easy as MXML, but it's less know and less
>> documented (OMG, I needed to look into qxtransform source code to
>> learn about QXML! :-) ). But it's a wonderful product.
>>
>> Flex and ActionScript have integration with many IDEs, but so far I
>> didn't see any IDE with qooxdoo support or even QxTransform support.
>
> That's true, for the javascript part (I personally hate to use XML as a 
> programing language).
I think descritive languages are good to design interfaces, mainly to
create via software. And I see the people like writing interfaces in
XML (XUL, MXML, XAML, HTML). But I know it's not the focus of qooxdoo.
 But it's a nice feature.

> It is due to some very positive part of qooxdoo : it is not only a js, but an 
> OO js.
> This is why I like qooxdoo but the consequence is that OO layer is not well 
> taken into account by IDE, even javascript IDE.
> Also, the Python build toolchain as to be integrated in the IDE.
> We did that using Ant script and it works for IntelliJ, Eclipse and NetBeans.
> If interested I can post the script that are really small and simple.
>
>> [CUT]
>
>
>>
>> The next gen web browser are going to use hardware acceleration to
>> "boost" web pages and web apps. Flash (used by Flex) already uses
>> hardware acceleration, so it's very fast and has cool animations on
>> it's interface.  I think qooxdoo could take advantages of threse new
>> browsers' tecnologies to improve it's performance. Are there any
>> iniciative in this way?
>
> Good question. I'm interested ...
>
>> There are also other interesting tecnologies
>> link video and audio (html5 tag) and even the canvas and svg element
>> which could be used to enrich the qooxdoo framework.
>>
>
> Yes and don't forget to mention offline use and local persistence with web 
> database.
> http://ajaxian.com/archives/offline-what-does-it-mean-and-why-should-i-care
>
>> [CUT]
>
>>
>> (IMHO) In this case, is essential to create an ecossystem around qooxdoo
>
> Yes, fully agree. In France, qooxdoo is mainly unknown.
> I was not able to get paid consultancy !
> There is an incredible situation for Qooxdoo : so good ant still unknown ... 
> (at least in France, not sure elsewhere)
> That's a real problem but strangely very few qooxdoo users appears aware of 
> that as a problem.
> I'd be happy to understand why but this would surely become a hot flaming 
> discussion, caution :-)
>
>
>> Composed by IDEs, documentation, forums, IRC channels (yes, I
>> miss a IRC channel :-( ), translation teams, etc.
>>
>
> qooxdoo IRC channel : #qooxdoo on irc.freenode.net
But this channel is always quite empty. Right now there are only 7
people there :-(
>
>> Thanks you qooxdoo developers.
>>
>> Best regards.
>
>
>
> --
> Automate Storage Tiering Simply
> Optimize IT performance and efficiency through flexible, powerful,
> automated storage tiering capabilities. View this brief to learn how
> you can reduce costs and improve performance.
> http://p.sf.net/sfu/dell-sfdev2dev
> ___
> qooxdoo-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>

--
Automate Storage Tiering Simply
Optimize IT performance and efficiency through flexible, powerful, 
automated storage tiering capabilities. View this brief to learn how
you can reduce costs and improve performance. 
http://p.sf.net/sfu/dell-sfdev2dev
___
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Re: [qooxdoo-devel] (off topic?) Qooxdoo's ecossystem question

2010-09-10 Thread thron7

On 09/10/2010 12:52 PM, Stefan Andersson wrote:
> Don't get me wrong, but if the core team knows everything, if you really
> mean everything, then, why using a community?
> 
> I think it was not really what you meant, because if you would think
> like that you make the biggest mistake and don't see what you think you do.
> 
> Despite of that, it is not most interesting what you know! Instead the
> interest lies in what you do NOT know! There the community can
> contribute a lot, because I think you admit now that you still don't
> know it ALL. Binary thinking does not work "mit Projekt Leitung", but is
> excellent with solving problems.
> 
> :-)
> 
> It lies a contradiction in what you said, so not to frighten new readers
> on this thread away, I only wanted to clarify.

I'm not really getting what you are hinting at here, because the context
of your lines is unclear to me.

But to pick up on one issue you *might* be aiming at, this list of mine
was not to silence people by saying "hey, we already know all of your
wishes", but rather to raise awareness that we are facing a very broad
range of topics, both within and without immediate visibility to the
casual observer, and that only a small fraction of them can be addressed
at anyone time. This gets easily overlooked when people think about the
question "why don't they do X?!".

We don't "use" our community (funny term, actually), we share. And
integrating new people into the project, in whatever role, is not an
easy task, especially as not many people are willing to go through a
process of regularly answering questions on the mailing list, open
well-documented bugs, provide patches, regularly submit edits for the
manual, take over responsibility for orphaned contributions, or create
and run a country- or domain-specific qooxdoo community on their own,
reliably and with a long-term commitment. Which I fully comprehend,
since everybody is fully absorbed with their own tasks. But that also
means many things are left undone.

T.

--
Automate Storage Tiering Simply
Optimize IT performance and efficiency through flexible, powerful, 
automated storage tiering capabilities. View this brief to learn how
you can reduce costs and improve performance. 
http://p.sf.net/sfu/dell-sfdev2dev
___
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Re: [qooxdoo-devel] (off topic?) Qooxdoo's ecossystem question

2010-09-10 Thread Jean-Baptiste BRIAUD -- Novlog


Trying to improve qooxdoo popularity has nothing to do with wish list.
I would love to simplify new comers life only because I love qooxdoo and I feel 
that qooxdoo popularity is too low.
That would not be something I need but something I think could improve qooxdoo 
popularity.
Already listed and discussed : optional python tool chain and all in one js 
file to download.
This ideas was not shared so it was probably not a good idea.

The question was about an ecosystem, not wish list from different user.
Also, it may not be obvious for everybody why an ecosystem is a good thing to 
have and why we don't have one for qooxdoo.
If I remember well, even increasing qooxdoo popularity was not something 
obvious for everybody.

>From last discussion, I noticed that the feeling for qooxdoo popularity and 
>ecosystem state is quite different depending on country and in Germany, 
>probably because 1&1 is well known, the situation is not bad at all.
Here in France, I was simply not able to get paid consultancy on qooxdoo, so 
the ecosystem is just undefined, not even null :-)

Of course, that doesn't change the reality of what we have all : the best web 
framework on a technical point of view, thanks to qooxdoo core team.

On 10 sept. 2010, at 13:13, John Spackman wrote:

> Sounds great Thomas, and it would be perfect to have that list completed
> by, say, next Friday? ;)
> 
> 
> Seriously though, it's not surprising that different Qx users have
> different priorities and out of these the core Qx team have a task to
> filter out the "real" set (not ignoring 1&1's commercial needs either),
> but most people (myself included) do not have the time or money to back up
> our requests with actual contributions.
> 
> Qooxdoo's core todo list is pretty massive and we have to recognise that
> many (most?) of our wish list won't get done soon even though there are
> several people on the list with overlapping requirements.
> 
> So how about setting up a kind of marketplace for jobs to be done where
> people group together to pay a "prize" for the best or quickest entry?
> For example, new themes: if 5 people/companies each donated £100 for a new
> theme, that's £500 (around US$750) that goes to the person voted as giving
> the best theme; the contrib would have to be OS licensed and gifted to Qx
> to qualify.
> 
> Obviously this depends on enough people getting together to define
> _and_agree_ the project, as well as enough entrants - but I wouldn't see a
> problem in paying someone who was also paid by his employer to develop the
> solution (so long as the contrib is OS licensed).
> 
> John
> 
> On 10/09/2010 10:58, "thron7"  wrote:
> 
>> Wishlist for qooxdoo
>> 
>> (by whomsoever, in no particular order, with no particular preference,
>> and with no implied commit status):
>> 
>> * add 2 new standard themes
>> * re-design the web site
>> * finalize move of the web site to new hardware (we're still using the
>> old one as well)
>> * improve the manual
>> * re-write the manual
>> * write a book about qooxdoo
>> * write more tutorials
>> * hold more tutorials  (we came just back from Bucharest doing that)
>> * replace the mailing list with something better
>> * replace bugzilla with something better
>> * replace the wiki with something better
>> * write more blog posts
>> * answer more blog posts
>> * write more tweets
>> * write more answers on the mailing list
>> * write less(!) answers on the mailing list
>> * provide IDE support for qooxdoo
>> * provide an interface builder for qooxdoo
>> * provide a GUI for the generator
>> * re-write the generator
>> * make the generator faster
>> * make the generator use multi-core
>> * improve the framework API
>> * keep the framework API stable
>> * write more unit tests
>> * publish test results
>> * test test coverage (no typo!)
>> * move the test infrastructure to a dedicated host
>> * fix bugs for the next release
>> * implement features for the next release
>> * advertise qooxdoo to inhouse projects
>> * teach qooxdoo to inhouse projects
>> * support inhouse projects
>> * add virtual widgets
>> * add lightweight widgets
>> * write the next killer demo
>> * implement the next killer JS feature
>> * ...
>> 
>> These are only the first things that come to my mind. Shall I continue?!
>> 
>> T.
>> 
>> On 09/10/2010 11:01 AM, Tom Schindl wrote:
>>> Hi,
>>> 
>>> I've often tried that but when I point people to the show case the
>>> biggest problem is that if you compare the L&F with the one from the
>>> competitors (ext, smartclient, ...) qooxdoo can't compete - we can argue
>>> a long way that the code quality and the design of qooxdoo is better but
>>> you'll won't get people to buy into qooxdoo with giving them a default
>>> state of the art visual design.
>>> 
>>> What qooxdoo needs are 2 new designs:
>>> * a very flashy one (the one from Norbert is going into the right
>>>  direction)
>>> * one a bit more conservative one than the above to catch up with
>>>  competitors
>>> 
>>> To

Re: [qooxdoo-devel] (off topic?) Qooxdoo's ecossystem question

2010-09-10 Thread thron7



> 1. So why not ask some people outside the core to contribute and
> actively assign them for some of the work, but still letting the core
> team be supervising it?
> 
> 2. We are a bunch of people here. Why not let people commit to spreading
> the message of qooxdoo? For example, it could be nice to ask someone
> specific person to...
> 
> ...become the unofficial representative/ambassador in a country
> ...find out the best fora in that country
> ...spread the info about qooxdoo through them
> 
> The core team could write an instruction on how to do it, how to write,
> links, how to attract interest etc.
> 
> Essential here is to have a very simple start kit and all links go to
> the start kit, which takes seconds to get up and running.
> 
> 
> Is this possible to make happen?

First of all, it's another point on the list (or three). Community
building and management is nothing short of a full-time job.

T.

--
Automate Storage Tiering Simply
Optimize IT performance and efficiency through flexible, powerful, 
automated storage tiering capabilities. View this brief to learn how
you can reduce costs and improve performance. 
http://p.sf.net/sfu/dell-sfdev2dev
___
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Re: [qooxdoo-devel] (off topic?) Qooxdoo's ecossystem question

2010-09-10 Thread John Spackman

Sounds great Thomas, and it would be perfect to have that list completed
by, say, next Friday? ;)

Seriously though, it's not surprising that different Qx users have
different priorities and out of these the core Qx team have a task to
filter out the "real" set (not ignoring 1&1's commercial needs either),
but most people (myself included) do not have the time or money to back up
our requests with actual contributions.

Qooxdoo's core todo list is pretty massive and we have to recognise that
many (most?) of our wish list won't get done soon even though there are
several people on the list with overlapping requirements.

So how about setting up a kind of marketplace for jobs to be done where
people group together to pay a "prize" for the best or quickest entry?
For example, new themes: if 5 people/companies each donated £100 for a new
theme, that's £500 (around US$750) that goes to the person voted as giving
the best theme; the contrib would have to be OS licensed and gifted to Qx
to qualify.

Obviously this depends on enough people getting together to define
_and_agree_ the project, as well as enough entrants - but I wouldn't see a
problem in paying someone who was also paid by his employer to develop the
solution (so long as the contrib is OS licensed).

John

On 10/09/2010 10:58, "thron7"  wrote:

>Wishlist for qooxdoo
>
>(by whomsoever, in no particular order, with no particular preference,
>and with no implied commit status):
>
>* add 2 new standard themes
>* re-design the web site
>* finalize move of the web site to new hardware (we're still using the
>old one as well)
>* improve the manual
>* re-write the manual
>* write a book about qooxdoo
>* write more tutorials
>* hold more tutorials  (we came just back from Bucharest doing that)
>* replace the mailing list with something better
>* replace bugzilla with something better
>* replace the wiki with something better
>* write more blog posts
>* answer more blog posts
>* write more tweets
>* write more answers on the mailing list
>* write less(!) answers on the mailing list
>* provide IDE support for qooxdoo
>* provide an interface builder for qooxdoo
>* provide a GUI for the generator
>* re-write the generator
>* make the generator faster
>* make the generator use multi-core
>* improve the framework API
>* keep the framework API stable
>* write more unit tests
>* publish test results
>* test test coverage (no typo!)
>* move the test infrastructure to a dedicated host
>* fix bugs for the next release
>* implement features for the next release
>* advertise qooxdoo to inhouse projects
>* teach qooxdoo to inhouse projects
>* support inhouse projects
>* add virtual widgets
>* add lightweight widgets
>* write the next killer demo
>* implement the next killer JS feature
>* ...
>
>These are only the first things that come to my mind. Shall I continue?!
>
>T.
>
>On 09/10/2010 11:01 AM, Tom Schindl wrote:
>> Hi,
>> 
>> I've often tried that but when I point people to the show case the
>> biggest problem is that if you compare the L&F with the one from the
>> competitors (ext, smartclient, ...) qooxdoo can't compete - we can argue
>> a long way that the code quality and the design of qooxdoo is better but
>> you'll won't get people to buy into qooxdoo with giving them a default
>> state of the art visual design.
>> 
>> What qooxdoo needs are 2 new designs:
>> * a very flashy one (the one from Norbert is going into the right
>>   direction)
>> * one a bit more conservative one than the above to catch up with
>>   competitors
>> 
>> Tom
>> 
>> Am 10.09.10 10:46, schrieb Daniel Wagner:
>>> Here's one thing that could help a lot: If you come across an
>>> interesting blog post or discussion where other frameworks are
>>> mentioned, leave a comment suggesting people check out qooxdoo. Just
>>> don't be too "evangelical" about it, let people discover qooxdoo's
>>> strengths on their own.
>>>
>>>
>>> Regards,
>>> Daniel
>>>
>>> Jean-Baptiste BRIAUD -- Novlog schrieb:
 Hi Stefan,

 I would not be able to summarize as well as you did.
 This is the 100% exact copy of what I think :-)

 Thanks.

 Now, why not consider the second stage : what can we do all as a
community ?
 Any idea ?

 On 10 sept. 2010, at 09:38, Stefan Andersson wrote:

> Hej!
>
> I agree on your interest and I can assure that qooxdoo is the best
>for 
> many settings. Maybe not satisfies all tastes, but I have not found
> anything more complete out there. I am sure that the core team will
>be 
> adding functionality as browsers change. You have to be aware of it
>is 
> a slow process to upgrade all browsers out there and therefore the
> work with new implementations must have some degree of backward
> compatibility.
>
> Fortunately, qooxdoo is definitively one of the, if not the most,
> advanced javascript framework in the market. The design is really
>good 
> and in some parts based on

Re: [qooxdoo-devel] (off topic?) Qooxdoo's ecossystem question

2010-09-10 Thread Stefan Andersson


Don't get me wrong, but if the core team knows everything, if you really mean 
everything, then, why using a community?

I think it was not really what you meant, because if you would think like that 
you make the biggest mistake and don't see what you think you do.

Despite of that, it is not most interesting what you know! Instead the interest 
lies in what you do NOT know! There the community can contribute a lot, because 
I think you admit now that you still don't know it ALL. Binary thinking does 
not work "mit Projekt Leitung", but is excellent with solving problems.

:-)

It lies a contradiction in what you said, so not to frighten new readers on 
this thread away, I only wanted to clarify.

Stefan
  --
Automate Storage Tiering Simply
Optimize IT performance and efficiency through flexible, powerful, 
automated storage tiering capabilities. View this brief to learn how
you can reduce costs and improve performance. 
http://p.sf.net/sfu/dell-sfdev2dev___
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Re: [qooxdoo-devel] (off topic?) Qooxdoo's ecossystem question

2010-09-10 Thread Stefan Andersson


My mail list handler might be rudimentary, but it kicks me back after changing 
so many timesSorry for that!

There are ideas.
There is a list, a long list, which requires more resources.
There is will.
There is wish.

1.
 So why not ask some people outside the core to contribute and actively 
assign them for some of the work, but still letting the core team be 
supervising it?

2. We are a bunch of people here. Why not let 
people commit to spreading the message of qooxdoo? For example, it could
 be nice to ask someone specific person to...

...become the unofficial representative/ambassador in a country
...find out the best fora in that country
...spread the info about qooxdoo through them

The core team could write an instruction on how to do it, how to write, links, 
how to attract interest etc.

Essential here is to have a very simple start kit and all links go to the start 
kit, which takes seconds to get up and running.


Is this possible to make happen?

Stefan--
Automate Storage Tiering Simply
Optimize IT performance and efficiency through flexible, powerful, 
automated storage tiering capabilities. View this brief to learn how
you can reduce costs and improve performance. 
http://p.sf.net/sfu/dell-sfdev2dev___
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Re: [qooxdoo-devel] (off topic?) Qooxdoo's ecossystem question

2010-09-10 Thread Martin Wittemann

Hey,
It is really interesting to catch up all the whole thread (as Thomas said, we 
were in Bucharest for a week). As Tobi said, there is from time to time some 
similar post here on the list with a lot of good ideas. I love to read those 
posts because it gives me an idea how you, as the community, like the project. 
But unfortunately, most of the ideas area already known in the core team. Just 
take a look at the list Thomas put up. There is a lot to do and be sure we will 
check of some of the stuff. But its all about setting priorities, sure 
everybody knows that from its own projects. ;) If you are interested in the 
priorities, you can always take a look at out bugzilla to follow what we are 
doing and planed to do.
Best,
Martin


Am 10.09.2010 um 11:58 schrieb thron7:

> Wishlist for qooxdoo
> 
> (by whomsoever, in no particular order, with no particular preference,
> and with no implied commit status):
> 
> * add 2 new standard themes
> * re-design the web site
> * finalize move of the web site to new hardware (we're still using the
> old one as well)
> * improve the manual
> * re-write the manual
> * write a book about qooxdoo
> * write more tutorials
> * hold more tutorials  (we came just back from Bucharest doing that)
> * replace the mailing list with something better
> * replace bugzilla with something better
> * replace the wiki with something better
> * write more blog posts
> * answer more blog posts
> * write more tweets
> * write more answers on the mailing list
> * write less(!) answers on the mailing list
> * provide IDE support for qooxdoo
> * provide an interface builder for qooxdoo
> * provide a GUI for the generator
> * re-write the generator
> * make the generator faster
> * make the generator use multi-core
> * improve the framework API
> * keep the framework API stable
> * write more unit tests
> * publish test results
> * test test coverage (no typo!)
> * move the test infrastructure to a dedicated host
> * fix bugs for the next release
> * implement features for the next release
> * advertise qooxdoo to inhouse projects
> * teach qooxdoo to inhouse projects
> * support inhouse projects
> * add virtual widgets
> * add lightweight widgets
> * write the next killer demo
> * implement the next killer JS feature
> * ...
> 
> These are only the first things that come to my mind. Shall I continue?!
> 
> T.
> 
> On 09/10/2010 11:01 AM, Tom Schindl wrote:
>> Hi,
>> 
>> I've often tried that but when I point people to the show case the
>> biggest problem is that if you compare the L&F with the one from the
>> competitors (ext, smartclient, ...) qooxdoo can't compete - we can argue
>> a long way that the code quality and the design of qooxdoo is better but
>> you'll won't get people to buy into qooxdoo with giving them a default
>> state of the art visual design.
>> 
>> What qooxdoo needs are 2 new designs:
>> * a very flashy one (the one from Norbert is going into the right
>>  direction)
>> * one a bit more conservative one than the above to catch up with
>>  competitors
>> 
>> Tom
>> 
>> Am 10.09.10 10:46, schrieb Daniel Wagner:
>>> Here's one thing that could help a lot: If you come across an 
>>> interesting blog post or discussion where other frameworks are 
>>> mentioned, leave a comment suggesting people check out qooxdoo. Just 
>>> don't be too "evangelical" about it, let people discover qooxdoo's 
>>> strengths on their own.
>>> 
>>> 
>>> Regards,
>>> Daniel
>>> 
>>> Jean-Baptiste BRIAUD -- Novlog schrieb:
 Hi Stefan,
 
 I would not be able to summarize as well as you did.
 This is the 100% exact copy of what I think :-)
 
 Thanks.
 
 Now, why not consider the second stage : what can we do all as a community 
 ?
 Any idea ?
 
 On 10 sept. 2010, at 09:38, Stefan Andersson wrote:
 
> Hej!
> 
> I agree on your interest and I can assure that qooxdoo is the best for 
> many settings. Maybe not satisfies all tastes, but I have not found 
> anything more complete out there. I am sure that the core team will be 
> adding functionality as browsers change. You have to be aware of it is 
> a slow process to upgrade all browsers out there and therefore the 
> work with new implementations must have some degree of backward 
> compatibility.
> 
> Fortunately, qooxdoo is definitively one of the, if not the most, 
> advanced javascript framework in the market. The design is really good 
> and in some parts based on excellent new ideas. Javascript is not an 
> easy language to build a framework on! Lots of tricks to get it 
> going...mostly due to a rain forest of wild browsers living their own 
> lives.
> 
> Unfortunately, qooxdoo is more or less a garage project from a 
> marketing perspective. Very few know of it in the world. The website 
> is in its functionality average, but its design is already old. Almost 
> no money and too little time is spent on mark

Re: [qooxdoo-devel] (off topic?) Qooxdoo's ecossystem question

2010-09-10 Thread thron7

Wishlist for qooxdoo

(by whomsoever, in no particular order, with no particular preference,
and with no implied commit status):

* add 2 new standard themes
* re-design the web site
* finalize move of the web site to new hardware (we're still using the
old one as well)
* improve the manual
* re-write the manual
* write a book about qooxdoo
* write more tutorials
* hold more tutorials  (we came just back from Bucharest doing that)
* replace the mailing list with something better
* replace bugzilla with something better
* replace the wiki with something better
* write more blog posts
* answer more blog posts
* write more tweets
* write more answers on the mailing list
* write less(!) answers on the mailing list
* provide IDE support for qooxdoo
* provide an interface builder for qooxdoo
* provide a GUI for the generator
* re-write the generator
* make the generator faster
* make the generator use multi-core
* improve the framework API
* keep the framework API stable
* write more unit tests
* publish test results
* test test coverage (no typo!)
* move the test infrastructure to a dedicated host
* fix bugs for the next release
* implement features for the next release
* advertise qooxdoo to inhouse projects
* teach qooxdoo to inhouse projects
* support inhouse projects
* add virtual widgets
* add lightweight widgets
* write the next killer demo
* implement the next killer JS feature
* ...

These are only the first things that come to my mind. Shall I continue?!

T.

On 09/10/2010 11:01 AM, Tom Schindl wrote:
> Hi,
> 
> I've often tried that but when I point people to the show case the
> biggest problem is that if you compare the L&F with the one from the
> competitors (ext, smartclient, ...) qooxdoo can't compete - we can argue
> a long way that the code quality and the design of qooxdoo is better but
> you'll won't get people to buy into qooxdoo with giving them a default
> state of the art visual design.
> 
> What qooxdoo needs are 2 new designs:
> * a very flashy one (the one from Norbert is going into the right
>   direction)
> * one a bit more conservative one than the above to catch up with
>   competitors
> 
> Tom
> 
> Am 10.09.10 10:46, schrieb Daniel Wagner:
>> Here's one thing that could help a lot: If you come across an 
>> interesting blog post or discussion where other frameworks are 
>> mentioned, leave a comment suggesting people check out qooxdoo. Just 
>> don't be too "evangelical" about it, let people discover qooxdoo's 
>> strengths on their own.
>>
>>
>> Regards,
>> Daniel
>>
>> Jean-Baptiste BRIAUD -- Novlog schrieb:
>>> Hi Stefan,
>>>
>>> I would not be able to summarize as well as you did.
>>> This is the 100% exact copy of what I think :-)
>>>
>>> Thanks.
>>>
>>> Now, why not consider the second stage : what can we do all as a community ?
>>> Any idea ?
>>>
>>> On 10 sept. 2010, at 09:38, Stefan Andersson wrote:
>>>
 Hej!

 I agree on your interest and I can assure that qooxdoo is the best for 
 many settings. Maybe not satisfies all tastes, but I have not found 
 anything more complete out there. I am sure that the core team will be 
 adding functionality as browsers change. You have to be aware of it is 
 a slow process to upgrade all browsers out there and therefore the 
 work with new implementations must have some degree of backward 
 compatibility.

 Fortunately, qooxdoo is definitively one of the, if not the most, 
 advanced javascript framework in the market. The design is really good 
 and in some parts based on excellent new ideas. Javascript is not an 
 easy language to build a framework on! Lots of tricks to get it 
 going...mostly due to a rain forest of wild browsers living their own 
 lives.

 Unfortunately, qooxdoo is more or less a garage project from a 
 marketing perspective. Very few know of it in the world. The website 
 is in its functionality average, but its design is already old. Almost 
 no money and too little time is spent on marketing of this fantastic 
 tool. Until that will be done, it will still be in the garage 
 division. Unfortunately development goes fast and the competitors 
 don't wait. Especially not the commercial alternatives. One scenario 
 could be an alliance with one of the big market players. We have not 
 seen this happen so far. If nothing drastic happens, it will still be 
 a small alternative, but maybe still technically the best.

 Even though this insecurity due to the market and fame, we chose 
 qooxdoo because the code has been fairly well documented, the 
 structure is robust and it is technically the best. It still has a lot 
 of things to improve, but already now it is the best. We have 
 developed about 1,200,000 lines of "qooxdoo" code and converted a 
 system which soon will "fly"... We are satisfied about it. The support 
 is fast and mostly accurate. The core team is mostly very skilled

Re: [qooxdoo-devel] (off topic?) Qooxdoo's ecossystem question

2010-09-10 Thread Tom Schindl

thron7 schrieb:
> 
> On 09/10/2010 11:01 AM, Tom Schindl wrote:
>> Hi,
>>
>> I've often tried that but when I point people to the show case the
>> biggest problem is that if you compare the L&F with the one from the
>> competitors (ext, smartclient, ...) qooxdoo can't compete - we can argue
>> a long way that the code quality and the design of qooxdoo is better but
>> you'll won't get people to buy into qooxdoo with giving them a default
> 
> ... *without* ...?!

Yep.

Tom

--
Automate Storage Tiering Simply
Optimize IT performance and efficiency through flexible, powerful, 
automated storage tiering capabilities. View this brief to learn how
you can reduce costs and improve performance. 
http://p.sf.net/sfu/dell-sfdev2dev
___
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Re: [qooxdoo-devel] (off topic?) Qooxdoo's ecossystem question

2010-09-10 Thread Jean-Baptiste BRIAUD -- Novlog

Sure we can all post, blog, comment in favor of qooxdoo.
I do that as much as I can already.

There is also some other idea that would involve qooxdoo : 
* make it simpler to use for first time user (Python toolchain optional rather 
than mandatory, all in one big js file to download, ...)
* better default theme

That had been discussed many times.

On 10 sept. 2010, at 10:46, Daniel Wagner wrote:

> Here's one thing that could help a lot: If you come across an 
> interesting blog post or discussion where other frameworks are 
> mentioned, leave a comment suggesting people check out qooxdoo. Just 
> don't be too "evangelical" about it, let people discover qooxdoo's 
> strengths on their own.
> 
> 
> Regards,
> Daniel
> 
> Jean-Baptiste BRIAUD -- Novlog schrieb:
>> Hi Stefan,
>> 
>> I would not be able to summarize as well as you did.
>> This is the 100% exact copy of what I think :-)
>> 
>> Thanks.
>> 
>> Now, why not consider the second stage : what can we do all as a community ?
>> Any idea ?
>> 
>> On 10 sept. 2010, at 09:38, Stefan Andersson wrote:
>> 
>>> Hej!
>>> 
>>> I agree on your interest and I can assure that qooxdoo is the best for 
>>> many settings. Maybe not satisfies all tastes, but I have not found 
>>> anything more complete out there. I am sure that the core team will be 
>>> adding functionality as browsers change. You have to be aware of it is 
>>> a slow process to upgrade all browsers out there and therefore the 
>>> work with new implementations must have some degree of backward 
>>> compatibility.
>>> 
>>> Fortunately, qooxdoo is definitively one of the, if not the most, 
>>> advanced javascript framework in the market. The design is really good 
>>> and in some parts based on excellent new ideas. Javascript is not an 
>>> easy language to build a framework on! Lots of tricks to get it 
>>> going...mostly due to a rain forest of wild browsers living their own 
>>> lives.
>>> 
>>> Unfortunately, qooxdoo is more or less a garage project from a 
>>> marketing perspective. Very few know of it in the world. The website 
>>> is in its functionality average, but its design is already old. Almost 
>>> no money and too little time is spent on marketing of this fantastic 
>>> tool. Until that will be done, it will still be in the garage 
>>> division. Unfortunately development goes fast and the competitors 
>>> don't wait. Especially not the commercial alternatives. One scenario 
>>> could be an alliance with one of the big market players. We have not 
>>> seen this happen so far. If nothing drastic happens, it will still be 
>>> a small alternative, but maybe still technically the best.
>>> 
>>> Even though this insecurity due to the market and fame, we chose 
>>> qooxdoo because the code has been fairly well documented, the 
>>> structure is robust and it is technically the best. It still has a lot 
>>> of things to improve, but already now it is the best. We have 
>>> developed about 1,200,000 lines of "qooxdoo" code and converted a 
>>> system which soon will "fly"... We are satisfied about it. The support 
>>> is fast and mostly accurate. The core team is mostly very skilled in 
>>> its answers. But we would never choose qooxdoo for such a big project 
>>> without knowing we have our own resources if qooxdoo dies or if the 
>>> qooxdoo team disappears in some or the other way. Too big investment 
>>> and too big risk, if we wouldn't have the resources by ourselves.
>>> 
>>> I hope the above clarifies one of many views from the community.
>>> 
>>> Stefan
>>> --
>>> Automate Storage Tiering Simply
>>> Optimize IT performance and efficiency through flexible, powerful, 
>>> automated storage tiering capabilities. View this brief to learn how
>>> you can reduce costs and improve performance. 
>>> http://p.sf.net/sfu/dell-sfdev2dev___
>>> qooxdoo-devel mailing list
>>> [email protected] 
>>> 
>>> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>> 
>> 
>> 
>> 
>> --
>> Automate Storage Tiering Simply
>> Optimize IT performance and efficiency through flexible, powerful, 
>> automated storage tiering capabilities. View this brief to learn how
>> you can reduce costs and improve performance. 
>> http://p.sf.net/sfu/dell-sfdev2dev
>> 
>> 
>> 
>> 
>> ___
>> qooxdoo-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
> 
> --
> Automate Storage Tiering Simply
> Optimize IT performance and efficiency through fle

Re: [qooxdoo-devel] (off topic?) Qooxdoo's ecossystem question

2010-09-10 Thread thron7

On 09/10/2010 11:01 AM, Tom Schindl wrote:
> Hi,
> 
> I've often tried that but when I point people to the show case the
> biggest problem is that if you compare the L&F with the one from the
> competitors (ext, smartclient, ...) qooxdoo can't compete - we can argue
> a long way that the code quality and the design of qooxdoo is better but
> you'll won't get people to buy into qooxdoo with giving them a default

... *without* ...?!

> state of the art visual design.
> 
> What qooxdoo needs are 2 new designs:
> * a very flashy one (the one from Norbert is going into the right
>   direction)
> * one a bit more conservative one than the above to catch up with
>   competitors
> 
> Tom
> 
> Am 10.09.10 10:46, schrieb Daniel Wagner:
>> Here's one thing that could help a lot: If you come across an 
>> interesting blog post or discussion where other frameworks are 
>> mentioned, leave a comment suggesting people check out qooxdoo. Just 
>> don't be too "evangelical" about it, let people discover qooxdoo's 
>> strengths on their own.
>>
>>
>> Regards,
>> Daniel
>>
>> Jean-Baptiste BRIAUD -- Novlog schrieb:
>>> Hi Stefan,
>>>
>>> I would not be able to summarize as well as you did.
>>> This is the 100% exact copy of what I think :-)
>>>
>>> Thanks.
>>>
>>> Now, why not consider the second stage : what can we do all as a community ?
>>> Any idea ?
>>>
>>> On 10 sept. 2010, at 09:38, Stefan Andersson wrote:
>>>
 Hej!

 I agree on your interest and I can assure that qooxdoo is the best for 
 many settings. Maybe not satisfies all tastes, but I have not found 
 anything more complete out there. I am sure that the core team will be 
 adding functionality as browsers change. You have to be aware of it is 
 a slow process to upgrade all browsers out there and therefore the 
 work with new implementations must have some degree of backward 
 compatibility.

 Fortunately, qooxdoo is definitively one of the, if not the most, 
 advanced javascript framework in the market. The design is really good 
 and in some parts based on excellent new ideas. Javascript is not an 
 easy language to build a framework on! Lots of tricks to get it 
 going...mostly due to a rain forest of wild browsers living their own 
 lives.

 Unfortunately, qooxdoo is more or less a garage project from a 
 marketing perspective. Very few know of it in the world. The website 
 is in its functionality average, but its design is already old. Almost 
 no money and too little time is spent on marketing of this fantastic 
 tool. Until that will be done, it will still be in the garage 
 division. Unfortunately development goes fast and the competitors 
 don't wait. Especially not the commercial alternatives. One scenario 
 could be an alliance with one of the big market players. We have not 
 seen this happen so far. If nothing drastic happens, it will still be 
 a small alternative, but maybe still technically the best.

 Even though this insecurity due to the market and fame, we chose 
 qooxdoo because the code has been fairly well documented, the 
 structure is robust and it is technically the best. It still has a lot 
 of things to improve, but already now it is the best. We have 
 developed about 1,200,000 lines of "qooxdoo" code and converted a 
 system which soon will "fly"... We are satisfied about it. The support 
 is fast and mostly accurate. The core team is mostly very skilled in 
 its answers. But we would never choose qooxdoo for such a big project 
 without knowing we have our own resources if qooxdoo dies or if the 
 qooxdoo team disappears in some or the other way. Too big investment 
 and too big risk, if we wouldn't have the resources by ourselves.

 I hope the above clarifies one of many views from the community.

 Stefan
 --
 Automate Storage Tiering Simply
 Optimize IT performance and efficiency through flexible, powerful, 
 automated storage tiering capabilities. View this brief to learn how
 you can reduce costs and improve performance. 
 http://p.sf.net/sfu/dell-sfdev2dev___
 qooxdoo-devel mailing list
 [email protected] 

 https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>>>
>>>
>>> 
>>>
>>> --
>>> Automate Storage Tiering Simply
>>> Optimize IT performance and efficiency through flexible, powerful, 
>>> automated storage tiering capabilities. View this brief to learn how
>>> you can reduce costs and improve performance. 
>>> http://p.sf.net/sfu/dell-sfdev2dev
>>>
>>>
>>> --

Re: [qooxdoo-devel] (off topic?) Qooxdoo's ecossystem question

2010-09-10 Thread Tom Schindl

Hi,

I've often tried that but when I point people to the show case the
biggest problem is that if you compare the L&F with the one from the
competitors (ext, smartclient, ...) qooxdoo can't compete - we can argue
a long way that the code quality and the design of qooxdoo is better but
you'll won't get people to buy into qooxdoo with giving them a default
state of the art visual design.

What qooxdoo needs are 2 new designs:
* a very flashy one (the one from Norbert is going into the right
  direction)
* one a bit more conservative one than the above to catch up with
  competitors

Tom

Am 10.09.10 10:46, schrieb Daniel Wagner:
> Here's one thing that could help a lot: If you come across an 
> interesting blog post or discussion where other frameworks are 
> mentioned, leave a comment suggesting people check out qooxdoo. Just 
> don't be too "evangelical" about it, let people discover qooxdoo's 
> strengths on their own.
> 
> 
> Regards,
> Daniel
> 
> Jean-Baptiste BRIAUD -- Novlog schrieb:
>> Hi Stefan,
>>
>> I would not be able to summarize as well as you did.
>> This is the 100% exact copy of what I think :-)
>>
>> Thanks.
>>
>> Now, why not consider the second stage : what can we do all as a community ?
>> Any idea ?
>>
>> On 10 sept. 2010, at 09:38, Stefan Andersson wrote:
>>
>>> Hej!
>>>
>>> I agree on your interest and I can assure that qooxdoo is the best for 
>>> many settings. Maybe not satisfies all tastes, but I have not found 
>>> anything more complete out there. I am sure that the core team will be 
>>> adding functionality as browsers change. You have to be aware of it is 
>>> a slow process to upgrade all browsers out there and therefore the 
>>> work with new implementations must have some degree of backward 
>>> compatibility.
>>>
>>> Fortunately, qooxdoo is definitively one of the, if not the most, 
>>> advanced javascript framework in the market. The design is really good 
>>> and in some parts based on excellent new ideas. Javascript is not an 
>>> easy language to build a framework on! Lots of tricks to get it 
>>> going...mostly due to a rain forest of wild browsers living their own 
>>> lives.
>>>
>>> Unfortunately, qooxdoo is more or less a garage project from a 
>>> marketing perspective. Very few know of it in the world. The website 
>>> is in its functionality average, but its design is already old. Almost 
>>> no money and too little time is spent on marketing of this fantastic 
>>> tool. Until that will be done, it will still be in the garage 
>>> division. Unfortunately development goes fast and the competitors 
>>> don't wait. Especially not the commercial alternatives. One scenario 
>>> could be an alliance with one of the big market players. We have not 
>>> seen this happen so far. If nothing drastic happens, it will still be 
>>> a small alternative, but maybe still technically the best.
>>>
>>> Even though this insecurity due to the market and fame, we chose 
>>> qooxdoo because the code has been fairly well documented, the 
>>> structure is robust and it is technically the best. It still has a lot 
>>> of things to improve, but already now it is the best. We have 
>>> developed about 1,200,000 lines of "qooxdoo" code and converted a 
>>> system which soon will "fly"... We are satisfied about it. The support 
>>> is fast and mostly accurate. The core team is mostly very skilled in 
>>> its answers. But we would never choose qooxdoo for such a big project 
>>> without knowing we have our own resources if qooxdoo dies or if the 
>>> qooxdoo team disappears in some or the other way. Too big investment 
>>> and too big risk, if we wouldn't have the resources by ourselves.
>>>
>>> I hope the above clarifies one of many views from the community.
>>>
>>> Stefan
>>> --
>>> Automate Storage Tiering Simply
>>> Optimize IT performance and efficiency through flexible, powerful, 
>>> automated storage tiering capabilities. View this brief to learn how
>>> you can reduce costs and improve performance. 
>>> http://p.sf.net/sfu/dell-sfdev2dev___
>>> qooxdoo-devel mailing list
>>> [email protected] 
>>> 
>>> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>>
>>
>> 
>>
>> --
>> Automate Storage Tiering Simply
>> Optimize IT performance and efficiency through flexible, powerful, 
>> automated storage tiering capabilities. View this brief to learn how
>> you can reduce costs and improve performance. 
>> http://p.sf.net/sfu/dell-sfdev2dev
>>
>>
>> 
>>
>> ___
>> qooxdoo-devel mailing list
>> [email protected]
>> https://list

Re: [qooxdoo-devel] (off topic?) Qooxdoo's ecossystem question

2010-09-10 Thread thron7

> Unfortunately, qooxdoo is more or less a garage project from a marketing
> perspective. Very few know of it in the world. The website is in its
> functionality average, but its design is already old. Almost no money
> and too little time is spent on marketing of this fantastic tool. Until
> that will be done, it will still be in the garage division.

I'm not sure it is all about money here. I would be surprised if other
open-source projects like dojo or jquery move major funds for marketing.
Maybe jquery can benefit from a Mozilla web designer for its web site,
but that might be about all ;-).

The thing I find more interesting is the fact that a channel like
Ajaxian.org simply drops mails from us about significant releases and
innovations (e.g. the forked out qx-oo.js recently), while any minuscule
achievement of other JS projects is hailed and reported about in depth.
I cannot help but feel a bit "underdoged" here.

I think in terms of overall recognition it is more a question of
word-of-mouth advertising, and we don't seem to have achieved a critical
mass in this respect. Blog posts, tweets and comments to popular posts
could do a lot here.

T.


--
Automate Storage Tiering Simply
Optimize IT performance and efficiency through flexible, powerful, 
automated storage tiering capabilities. View this brief to learn how
you can reduce costs and improve performance. 
http://p.sf.net/sfu/dell-sfdev2dev
___
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Re: [qooxdoo-devel] (off topic?) Qooxdoo's ecossystem question

2010-09-10 Thread Siarhei Barysiuk

Hi,

I can say only for qxtransformer cause I and Christian Boulanger  
started the project.

As you mentioned, the project is not very active. But it's compatible  
with the latest version of qooxdoo and works fine (use trunk version).  
The biggest project where qxtransformer was used is Bibliograph 
(http://sourceforge.net/projects/bibliograph/ 
) by Christian Boulanger.

We have tags docs here: http://qxtransformer.org/docs/
And some other documentation here: 
http://sites.google.com/a/qxtransformer.org/qxtransformer/Documentation
And here:
http://qooxdoo.org/contrib/project/qxtransformer/setup?s=qxtransformer
http://qooxdoo.org/contrib/project/qxtransformer/components?s=qxtransformer

Docs are not perfect (far from perfect) but unfortunately that what we  
have now. Since it's a pet project sometimes it's not enough time to  
improve things, writing docs, etc. All my current activities are not  
related with qooxdoo (unfortunately) and I don't have enough time to  
working on the project anymore.

If you (or any other developer/contributor) is interested in moving  
qxtransformer forward, please let me know. We will be glad to provide  
you with all necessary information and help.

Thanks,
Siarhei Barysiuk


On Sep 10, 2010, at 5:55 AM, Leandro Santiago wrote:

> Hello to all. (Sorry for my bad English, I'm Brazilian, I hope you
> understand me, and yes, it's a long text :-))
>
> I'm a qooxdoo fan's, even I being a newbie :-)
>
> I'm thinking in how qooxdoo is a great framework, but it isn't very
> know. Many people use other frameworks for RIA,  like Flex (here in
> Brazil it's very famous) or Silverlight and they usually spend a lot
> of money with these tools and other things.
>
> Flex is know for the MXML dialect. Qooxdoo is incredible and there is
> QxTransformer, which as easy as MXML, but it's less know and less
> documented (OMG, I needed to look into qxtransform source code to
> learn about QXML! :-) ). But it's a wonderful product.
>
> Flex and ActionScript have integration with many IDEs, but so far I
> didn't see any IDE with qooxdoo support or even QxTransform support.
>
> The documentation about QxTransformer is out of date (qooxdoo 0.8),
> and more complete tutorials about qooxdoo are missing.
>
> I know, it's a community project, but it has the power to be a very
> professional if there are companies and other associated projects,
> like IDEs and visual tools (for qxtransform).
>
> The next gen web browser are going to use hardware acceleration to
> "boost" web pages and web apps. Flash (used by Flex) already uses
> hardware acceleration, so it's very fast and has cool animations on
> it's interface.  I think qooxdoo could take advantages of threse new
> browsers' tecnologies to improve it's performance. Are there any
> iniciative in this way? There are also other interesting tecnologies
> link video and audio (html5 tag) and even the canvas and svg element
> which could be used to enrich the qooxdoo framework.
>
> I'm not complaining. I like qooxdoo and I think that it's its time.
> Many systems are migrating to web and unfortunately proprietary and
> closed source tecnologies are today the firsts in list of
> small/medium/big port companies.
>
> (IMHO) In this case, is essential to create an ecossystem around
> qooxdoo. Composed by IDEs, documentation, forums, IRC channels (yes, I
> miss a IRC channel :-( ), translation teams, etc.
>
> Thanks you qooxdoo developers.
>
> Best regards.
>
> --
> Automate Storage Tiering Simply
> Optimize IT performance and efficiency through flexible, powerful,
> automated storage tiering capabilities. View this brief to learn how
> you can reduce costs and improve performance.
> http://p.sf.net/sfu/dell-sfdev2dev
> ___
> qooxdoo-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel


--
Automate Storage Tiering Simply
Optimize IT performance and efficiency through flexible, powerful, 
automated storage tiering capabilities. View this brief to learn how
you can reduce costs and improve performance. 
http://p.sf.net/sfu/dell-sfdev2dev
___
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Re: [qooxdoo-devel] (off topic?) Qooxdoo's ecossystem question

2010-09-10 Thread Daniel Wagner

Here's one thing that could help a lot: If you come across an 
interesting blog post or discussion where other frameworks are 
mentioned, leave a comment suggesting people check out qooxdoo. Just 
don't be too "evangelical" about it, let people discover qooxdoo's 
strengths on their own.


Regards,
Daniel

Jean-Baptiste BRIAUD -- Novlog schrieb:
> Hi Stefan,
> 
> I would not be able to summarize as well as you did.
> This is the 100% exact copy of what I think :-)
> 
> Thanks.
> 
> Now, why not consider the second stage : what can we do all as a community ?
> Any idea ?
> 
> On 10 sept. 2010, at 09:38, Stefan Andersson wrote:
> 
>> Hej!
>>
>> I agree on your interest and I can assure that qooxdoo is the best for 
>> many settings. Maybe not satisfies all tastes, but I have not found 
>> anything more complete out there. I am sure that the core team will be 
>> adding functionality as browsers change. You have to be aware of it is 
>> a slow process to upgrade all browsers out there and therefore the 
>> work with new implementations must have some degree of backward 
>> compatibility.
>>
>> Fortunately, qooxdoo is definitively one of the, if not the most, 
>> advanced javascript framework in the market. The design is really good 
>> and in some parts based on excellent new ideas. Javascript is not an 
>> easy language to build a framework on! Lots of tricks to get it 
>> going...mostly due to a rain forest of wild browsers living their own 
>> lives.
>>
>> Unfortunately, qooxdoo is more or less a garage project from a 
>> marketing perspective. Very few know of it in the world. The website 
>> is in its functionality average, but its design is already old. Almost 
>> no money and too little time is spent on marketing of this fantastic 
>> tool. Until that will be done, it will still be in the garage 
>> division. Unfortunately development goes fast and the competitors 
>> don't wait. Especially not the commercial alternatives. One scenario 
>> could be an alliance with one of the big market players. We have not 
>> seen this happen so far. If nothing drastic happens, it will still be 
>> a small alternative, but maybe still technically the best.
>>
>> Even though this insecurity due to the market and fame, we chose 
>> qooxdoo because the code has been fairly well documented, the 
>> structure is robust and it is technically the best. It still has a lot 
>> of things to improve, but already now it is the best. We have 
>> developed about 1,200,000 lines of "qooxdoo" code and converted a 
>> system which soon will "fly"... We are satisfied about it. The support 
>> is fast and mostly accurate. The core team is mostly very skilled in 
>> its answers. But we would never choose qooxdoo for such a big project 
>> without knowing we have our own resources if qooxdoo dies or if the 
>> qooxdoo team disappears in some or the other way. Too big investment 
>> and too big risk, if we wouldn't have the resources by ourselves.
>>
>> I hope the above clarifies one of many views from the community.
>>
>> Stefan
>> --
>> Automate Storage Tiering Simply
>> Optimize IT performance and efficiency through flexible, powerful, 
>> automated storage tiering capabilities. View this brief to learn how
>> you can reduce costs and improve performance. 
>> http://p.sf.net/sfu/dell-sfdev2dev___
>> qooxdoo-devel mailing list
>> [email protected] 
>> 
>> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
> 
> 
> 
> 
> --
> Automate Storage Tiering Simply
> Optimize IT performance and efficiency through flexible, powerful, 
> automated storage tiering capabilities. View this brief to learn how
> you can reduce costs and improve performance. 
> http://p.sf.net/sfu/dell-sfdev2dev
> 
> 
> 
> 
> ___
> qooxdoo-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

--
Automate Storage Tiering Simply
Optimize IT performance and efficiency through flexible, powerful, 
automated storage tiering capabilities. View this brief to learn how
you can reduce costs and improve performance. 
http://p.sf.net/sfu/dell-sfdev2dev
___
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Re: [qooxdoo-devel] (off topic?) Qooxdoo's ecossystem question

2010-09-10 Thread Jean-Baptiste BRIAUD -- Novlog

Hi Stefan,

I would not be able to summarize as well as you did.
This is the 100% exact copy of what I think :-)

Thanks.

Now, why not consider the second stage : what can we do all as a community ?
Any idea ?

On 10 sept. 2010, at 09:38, Stefan Andersson wrote:

> Hej!
> 
> I agree on your interest and I can assure that qooxdoo is the best for many 
> settings. Maybe not satisfies all tastes, but I have not found anything more 
> complete out there. I am sure that the core team will be adding functionality 
> as browsers change. You have to be aware of it is a slow process to upgrade 
> all browsers out there and therefore the work with new implementations must 
> have some degree of backward compatibility.
> 
> Fortunately, qooxdoo is definitively one of the, if not the most, advanced 
> javascript framework in the market. The design is really good and in some 
> parts based on excellent new ideas. Javascript is not an easy language to 
> build a framework on! Lots of tricks to get it going...mostly due to a rain 
> forest of wild browsers living their own lives.
> 
> Unfortunately, qooxdoo is more or less a garage project from a marketing 
> perspective. Very few know of it in the world. The website is in its 
> functionality average, but its design is already old. Almost no money and too 
> little time is spent on marketing of this fantastic tool. Until that will be 
> done, it will still be in the garage division. Unfortunately development goes 
> fast and the competitors don't wait. Especially not the commercial 
> alternatives. One scenario could be an alliance with one of the big market 
> players. We have not seen this happen so far. If nothing drastic happens, it 
> will still be a small alternative, but maybe still technically the best.
> 
> Even though this insecurity due to the market and fame, we chose qooxdoo 
> because the code has been fairly well documented, the structure is robust and 
> it is technically the best. It still has a lot of things to improve, but 
> already now it is the best. We have developed about 1,200,000 lines of 
> "qooxdoo" code and converted a system which soon will "fly"... We are 
> satisfied about it. The support is fast and mostly accurate. The core team is 
> mostly very skilled in its answers. But we would never choose qooxdoo for 
> such a big project without knowing we have our own resources if qooxdoo dies 
> or if the qooxdoo team disappears in some or the other way. Too big 
> investment and too big risk, if we wouldn't have the resources by ourselves.
> 
> I hope the above clarifies one of many views from the community.
> 
> Stefan
> --
> Automate Storage Tiering Simply
> Optimize IT performance and efficiency through flexible, powerful, 
> automated storage tiering capabilities. View this brief to learn how
> you can reduce costs and improve performance. 
> http://p.sf.net/sfu/dell-sfdev2dev___
> qooxdoo-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

--
Automate Storage Tiering Simply
Optimize IT performance and efficiency through flexible, powerful, 
automated storage tiering capabilities. View this brief to learn how
you can reduce costs and improve performance. 
http://p.sf.net/sfu/dell-sfdev2dev___
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Re: [qooxdoo-devel] (off topic?) Qooxdoo's ecossystem question

2010-09-10 Thread Stefan Andersson


Hej!

I agree on your interest and I can assure that qooxdoo is the best for many 
settings. Maybe not satisfies all tastes, but I have not found anything more 
complete out there. I am sure that the core team will be adding functionality 
as browsers change. You have to be aware of it is a slow process to upgrade all 
browsers out there and therefore the work with new implementations must have 
some degree of backward compatibility.

Fortunately, qooxdoo is definitively one of the, if not the most, advanced 
javascript framework in the market. The design is really good and in some parts 
based on excellent new ideas. Javascript is not an easy language to build a 
framework on! Lots of tricks to get it going...mostly due to a rain forest of 
wild browsers living their own lives.

Unfortunately, qooxdoo is more or less a garage project from a marketing 
perspective. Very few know of it in the world. The website is in its 
functionality average, but its design is already old. Almost no money and too 
little time is spent on marketing of this fantastic tool. Until that will be 
done, it will still be in the garage division. Unfortunately development goes 
fast and the competitors don't wait. Especially not the commercial 
alternatives. One scenario could be an alliance with one of the big market 
players. We have not seen this happen so far. If nothing drastic happens, it 
will still be a small alternative, but maybe still technically the best.

Even though this insecurity due to the market and fame, we chose qooxdoo 
because the code has been fairly well documented, the structure is robust and 
it is technically the best. It still has a lot of things to improve, but 
already now it is the best. We have developed about 1,200,000 lines of 
"qooxdoo" code and converted a system which soon will "fly"... We are satisfied 
about it. The support is fast and mostly accurate. The core team is mostly very 
skilled in its answers. But we would never choose qooxdoo for such a big 
project without knowing we have our own resources if qooxdoo dies or if the 
qooxdoo team disappears in some or the other way. Too big investment and too 
big risk, if we wouldn't have the resources by ourselves.

I hope the above clarifies one of many views from the community.

Stefan
  --
Automate Storage Tiering Simply
Optimize IT performance and efficiency through flexible, powerful, 
automated storage tiering capabilities. View this brief to learn how
you can reduce costs and improve performance. 
http://p.sf.net/sfu/dell-sfdev2dev___
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Re: [qooxdoo-devel] (off topic?) Qooxdoo's ecossystem question

2010-09-10 Thread Jean-Baptiste BRIAUD -- Novlog

Hi Leandro,

On 10 sept. 2010, at 04:55, Leandro Santiago wrote:

> Hello to all. (Sorry for my bad English, I'm Brazilian, I hope you
> understand me, and yes, it's a long text :-))
> 
> I'm a qooxdoo fan's, even I being a newbie :-)
> 

Welcome !

> I'm thinking in how qooxdoo is a great framework, but it isn't very
> know. Many people use other frameworks for RIA,  like Flex (here in
> Brazil it's very famous) or Silverlight and they usually spend a lot
> of money with these tools and other things.
> 

I agree.

> Flex is know for the MXML dialect. Qooxdoo is incredible and there is
> QxTransformer, which as easy as MXML, but it's less know and less
> documented (OMG, I needed to look into qxtransform source code to
> learn about QXML! :-) ). But it's a wonderful product.
> 
> Flex and ActionScript have integration with many IDEs, but so far I
> didn't see any IDE with qooxdoo support or even QxTransform support.

That's true, for the javascript part (I personally hate to use XML as a 
programing language).
It is due to some very positive part of qooxdoo : it is not only a js, but an 
OO js.
This is why I like qooxdoo but the consequence is that OO layer is not well 
taken into account by IDE, even javascript IDE.
Also, the Python build toolchain as to be integrated in the IDE.
We did that using Ant script and it works for IntelliJ, Eclipse and NetBeans.
If interested I can post the script that are really small and simple.

> [CUT]

> 
> The next gen web browser are going to use hardware acceleration to
> "boost" web pages and web apps. Flash (used by Flex) already uses
> hardware acceleration, so it's very fast and has cool animations on
> it's interface.  I think qooxdoo could take advantages of threse new
> browsers' tecnologies to improve it's performance. Are there any
> iniciative in this way?

Good question. I'm interested ...

> There are also other interesting tecnologies
> link video and audio (html5 tag) and even the canvas and svg element
> which could be used to enrich the qooxdoo framework.
> 

Yes and don't forget to mention offline use and local persistence with web 
database.
http://ajaxian.com/archives/offline-what-does-it-mean-and-why-should-i-care

> [CUT]

> 
> (IMHO) In this case, is essential to create an ecossystem around qooxdoo

Yes, fully agree. In France, qooxdoo is mainly unknown.
I was not able to get paid consultancy !
There is an incredible situation for Qooxdoo : so good ant still unknown ... 
(at least in France, not sure elsewhere)
That's a real problem but strangely very few qooxdoo users appears aware of 
that as a problem.
I'd be happy to understand why but this would surely become a hot flaming 
discussion, caution :-)

> Composed by IDEs, documentation, forums, IRC channels (yes, I
> miss a IRC channel :-( ), translation teams, etc.
> 

qooxdoo IRC channel : #qooxdoo on irc.freenode.net

> Thanks you qooxdoo developers.
> 
> Best regards.

--
Automate Storage Tiering Simply
Optimize IT performance and efficiency through flexible, powerful, 
automated storage tiering capabilities. View this brief to learn how
you can reduce costs and improve performance. 
http://p.sf.net/sfu/dell-sfdev2dev
___
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

61 matches

Mail list logo