WebOS Project seeking for developers

[Rorist]

Hello,

I'm on a project of "yet another WebOS on the market" and I'm looking
for motivated developers/designers.
The project is well ahead, base direction are set. What I would need
is great ideas and motivated coders to consolidate the core,
and solve high end problems about WebOS'es in general. Here is a quick
presentation of the technologies involved and key features:
- Using Google's Protocol Buffers for internal data
- Using mootools 1.2 as a base
- Fully Open Source Software, see below
- Framework oriented project, so it would be easy to create
applications for the OS. (GUI, Windows, Widgets, ...)
- Modular, load and install application easily
- Multiuser based (need security work)
- Bazaar as the VCS, Launchpad as the developement platform
- Server side is currently in PHP, but this is not the main part of
the project. So it's possible to migrate to Python.
- Using the Apple's work on Human Interface to create the best user
experience possible (lot of work here)

The future of the project has to be made, I like the idea of Cloud
Computing, and that's the point of Python. At the moment, it's all
about the user interface, but the control over the server behind would
be very important, and that could be your mission if you are
interested.

I'm looking for designers too. Actually, it's quite ready to create
some "themes" by just creating an other "default theme". It's all made
from the begining to have theme. Any help welcome on that, even just a
pure image model, or a complete CSS/XHTML theme. I already have a logo
designer, you can contact him if you are interested.

The project is FULLY open source, and even more, the core is under the
Public Domain.

Enough talk, for more information, you can go to:
main site: http://takos.info
developement: https://launchpad.net/takos
contact me: https://launchpad.net/~jbaubort

Hope to hear from you soon.
Amicably, JBA

 

[Thomas 'PointedEars' Lahn]

I'm on a project of "yet another WebOS on the market" and I'm looking
for motivated developers/designers.
[...]
Here is a quick presentation of the technologies involved and key
features:
- Using Google's Protocol Buffers for internal data
- Using mootools 1.2 as a base

No, thanks.


PointedEars

 

[Rorist]

I bet you don't like Mootools,
but can you please elaborate the No ?

 

[Thomas 'PointedEars' Lahn]

I bet you don't like Mootools,

Preferences don't enter into it. I don't develop for or with monolithic
junk code if I can avoid it.

but can you please elaborate the No ?

Ohh, /that/? It's a common expression of denial.


PointedEars

 

[Rorist]

Preferences don't enter into it.  I don't develop for or with monolithic
junk code if I can avoid it.

I can argument the choice of a framework, Mootools particularly.

- mootools is light enough that it's flexible, i'm not stuck with
complicated methods that i have to hack all around
- crossbrowser is painless with a good framework
- mootools is one of the fastest around with Dojo
- don't reinvent the wheel
- Mootools is modular, so I don't have to use all of the framework
(wich I actually did for now, until i know wich part I really don't
need)

Ohh, /that/? It's a common expression of denial.

No, I'm a learner, and such limited response don't really help me get
the point of what could be improved or understand why my choices would
be wrong from your point of view.

Thanks anyway for giving me a reason to argument such an important
part of my little project.

Cheer.

 

[David Mark]

I can argument the choice of a framework, Mootools particularly.

- mootools is light enough that it's flexible, i'm not stuck with

Light enough? Everything is relative.

complicated methods that i have to hack all around

It is an homage to Prototype, so it has lots of unneeded nonsense to
"work around" prototypal inheritance. As with Prototype, syntactic
sugar is used at the lowest levels, which is a far cry from efficient.

- crossbrowser is painless with a good framework

Name a good cross-browser framework. Last I checked, MooTools used
brain-dead browser sniffing, so it is at best multi-browser and the
affected code is instantly dated.

- mootools is one of the fastest around with Dojo

This is the type of generalized nonsense I have come to expect from
advocates of these sorts of frameworks. Relatively speaking, Dojo and
MooTools are slugs.

- don't reinvent the wheel

Pollywannacracker? MooTools is neither useful, nor an invention.

- Mootools is modular, so I don't have to use all of the framework

I'll give it that, but who needs modular junk?

(wich I actually did for now, until i know wich part I really don't
need)

Good luck with that!

No, I'm a learner, and such limited response don't really help me get

Paradoxically, you lecture about MooTools as if you are an authority
on browser scripting.

the point of what could be improved or understand why my choices would
be wrong from your point of view.

Try searching the archive (or learning the first thing about browser
scripting.)

Thanks anyway for giving me a reason to argument such an important
part of my little project.

You have thrown the game away. Your "little" Web OS project is doomed
from the start.

Cheer.

Boo.

 

[Rorist]

THAT's actually argumentation. Thanks for your anwser David.

Relatively speaking, Dojo and MooTools are slugs.

Relative to what ? My comparaison was relative to other JS frameworks.

I can understand lot's of people don't find fw usefull, so why bother
starting an other flamewar on the subject ?
If your have such concern, you may help me build a low level framework
wich will handle all the crossbrowser routines.

Paradoxically, you lecture about MooTools as if you are an authority on browser scripting.

I'm certainly not, but as I tested some of the fw out there, it was a
good start without having to spend monthes bother with crossbrowser
(yes, it's all about that).

Try searching the archive (or learning the first thing about browser scripting.)

I learned a lot on that project, I wasn't aware JS could be that
powerfull.
A lot of people complaining that JS is not intented to do what we use
it for now (and it's probably true), but it can.

You have thrown the game away. Your "little" Web OS project is doomed from the start.

You are probably right, because the main goal of the project is to
have FUN and LEARN such things.

Best regards.

 

[Thomas 'PointedEars' Lahn]

You are probably right, because the main goal of the project is to have
FUN and LEARN such things.

(Please don't SHOUT here.)

But that is the problem with not only using these libraries but having an
operating system(!) be based on them. For their authors have yet to take
the first step in the learning curve themselves, that is, to take everything
that one reads about JavaScript with a handful of salt.

So, if you really want to learn something in this project, you will have to
start from scratch; at least you will have to do *thorough* investigation on
every piece of foreign code that you use, and your own code. And in order
to make an assessment about code quality and best practices, you will have
to learn the basics of the language and the APIs that can be used with it.
This newsgroup can help there.

Please learn to post: <http://jibbering.com/faq/#posting>


PointedEars

 

[David Mark]

THAT's actually argumentation. Thanks for your anwser David.

WHAT is?

Relative to what ? My comparaison was relative to other JS frameworks.

That is difficult at best to test empirically. But by inspecting the
scripts, you can determine that the upper bounds of their efficiency
are well below what can be accomplished with well-designed, context-
specific code.

I can understand lot's of people don't find fw usefull, so why bother
starting an other flamewar on the subject ?

You don't understand. The "flame wars" you refer to are nothing but
the shrill ravings of the hopelessly indoctrinated. They are
typically waged by people without proper names or the ability to write
coherent sentences (e.g. jQuery Rulez!!!!) On the contrary, numerous
real arguments have been posted here over the years that serve to
debunk these frameworks beyond a shadow of a doubt.

If your have such concern, you may help me build a low level framework
wich will handle all the crossbrowser routines.

May I? Perhaps I already have.

I'm certainly not, but as I tested some of the fw out there, it was a
good start without having to spend monthes bother with crossbrowser
(yes, it's all about that).

But if your goal is cross-browser compatibility, these frameworks fall
well short. It doesn't matter how many bloggers and neophytes claim
otherwise.

I learned a lot on that project, I wasn't aware JS could be that
powerfull.

What project?

A lot of people complaining that JS is not intented to do what we use
it for now (and it's probably true), but it can.

People complain about all sorts of things, including posts in this
group that denigrate frameworks.

You are probably right, because the main goal of the project is to
have FUN and LEARN such things.

Then I am right. It is no fun at all relying on a black box of
browser sniffing.

[snip]

 

[John G Harris]

Hello,

I'm on a project of "yet another WebOS on the market" and

<snip>

What is a WebOS ?

John

 

[Rorist]

What is a WebOS ?

Hello,

there are many definitions. Basically it's an Operating System that is
accessed from a remote server.

For TakOS (my project), you have a "fake" OS in your web browser,
using windows, icons, taskbar, contextual menus; to have all your data
accessible everywhere, in the same environnement. WebOS are also known
as Web Desktop. See http://en.wikipedia.org/wiki/Web_desktop for more
information.

 

[David Mark]

Hello,

there are many definitions. Basically it's an Operating System that is
accessed from a remote server.

That's not one of them.

For TakOS (my project), you have a "fake" OS in your web browser,

Interesting take.

using windows, icons, taskbar, contextual menus; to have all your data

I'd like to see that.

accessible everywhere, in the same environnement. WebOS are also known
as Web Desktop. Seehttp://en.wikipedia.org/wiki/Web_desktopfor more
information.

I wouldn't rely on Wikipedia (of all things) for such information.

 

[Rorist]

there are many definitions. Basically it's an Operating System that is

That's not one of them.

Ok, s/Operating System/network service/. Happy ? Give me yours.

This is getting boring. I understand your point about mootools and
everything. But if I'm mistaken about an information, just correct it,
instead of beeing rude for nothing.

This is totaly non constructive, as is your other post about mootols.
Ok there may be some tricks here and there, but it was what you looked
for, you found it, bravo.

I'm now happy with mootools, it saved some time so I can move forward
to the point of my webapp. I'm now looking for help, and this
discussion is everything but helpfull.

 

[David Mark]

Ok, s/Operating System/network service/. Happy ? Give me yours.

No and no.

This is getting boring. I understand your point about mootools and
Yes.

[snip]


This is totaly non constructive

What is "totaly (sic) non constructive?" Anything that finds fault in
your posted assertions?

, as is your other post about mootols.

If you have anything to add to that, feel free.

Ok there may be some tricks here and there, but it was what you looked
for, you found it, bravo.

On the contrary, I started at line 1 and read until it turned my
stomach. As documented, "tricks" were found everywhere.

I'm now happy with mootools, it saved some time so I can move forward

And what makes you happy with it? Is that something you wish to
discuss? In light of the obviously poor code quality and your
admitted inability to judge code at all, it is hard to understand what
gives you this feeling.

to the point of my webapp. I'm now looking for help, and this
discussion is everything but helpfull.

You are the latest in a very long line of ambitious neophytes who come
in here, ask a few basic questions, get answers that raise further
questions and then summarily dismiss all of them as unhelpful.

Good luck!

 

[Gregor Kofler]

Rorist meinte:

Hello,

I'm on a project of "yet another WebOS on the market" and I'm looking
for motivated developers/designers.
The project is well ahead, base direction are set. What I would need
is great ideas and motivated coders to consolidate the core,
and solve high end problems about WebOS'es in general. Here is a quick
presentation of the technologies involved and key features:
- Using Google's Protocol Buffers for internal data
- Using mootools 1.2 as a base

I'm sure you gonna find plenty of interested hax0rz ready to join your
project of a "WebOS" - however, not here.

Gregor

 

[Rorist]

You are the latest in a very long line of ambitious neophytes who come

in here, ask a few basic questions, get answers that raise further
questions and then summarily dismiss all of them as unhelpful.

I didn't ask any question, and you didn't give any answer, but

Good luck!

Thanks

I was looking around for some of your work, and wasn't able to find
any, but trolls.
I should have known this place is a plato's cavern.

 

[Thomas 'PointedEars' Lahn]

I didn't ask any question, and you didn't give any answer, but

You did ask questions, and you have been given answers. That you don't like
the answers is your problem alone.

I was looking around for some of your work, and wasn't able to find
any, but trolls.

*You* are the luser.

I should have known this place is a plato's cavern.

FOAD


PointedEars, f1

 

[David Mark]

I didn't ask any question, and you didn't give any answer, but

Then what was that "Thanks for your anwser David" business?

Thanks

I was looking around for some of your work, and wasn't able to find
any, but trolls.

I'd look again.

[snip]

 

[jhuni]

Hello,

I'm on a project of "yet another WebOS on the market" and I'm looking
for motivated developers/designers.
The project is well ahead, base direction are set. What I would need
is great ideas and motivated coders to consolidate the core,
and solve high end problems about WebOS'es in general. Here is a quick
presentation of the technologies involved and key features:

Hi I downloaded your source code and I am quite interested in this I
took a while to look over your code. Anyways I have "<s>great</s>
ideas" in many areas to improve your project.

Documentation:
Your inline documentation quite frankly is quite lacking and from the
looks of it you used a script to extract most of the documentation.
Just look at the module os.widget that you made, putting that many
asterisks makes the code hard to read. There is more asterisks in some
parts of the code then there is text.

Anyways, please see POD http://en.wikipedia.org/wiki/Plain_Old_Documentation
I think this will greatly help I personally use it and it already has
tons of formats for it so you can convert it to HTML and tons of other
formats. Anyways in this respect you have something like:

/*
=head1 NAME
os.context - contextual menus
=head1 SYNOPSIS
This is basically where you put your example code so that people see
basically what it looks like.
=head1 DESCRIPTION
Please describe your modules more then just a sentence.
*/

If you do this then I will just be able to go into your module and it
will have a common format that makes sense, POD is what most
developers see all the time so rather then make them make sense of
your personal format why not help us out and use the POD layout? A
synopsis on the top of all your files would help. The next thing that
would be really awesome is an explanation of all your dependencies,
does this module have to be a part of the whole os? If so why is it in
the os namespace? In my operating system Widget.Dialog is separated
from the os namespace. Oh and a copyright notice saying 'Public
Domain' and and author notice 'Rorist' will also help.

If you do this then I hope to be able to try out the modules myself
(it is too hard to figure out right now).

 

[Rorist]

Hi,

Documentation:
Your inline documentation quite frankly is quite lacking and from the
looks of it you used a script to extract most of the documentation.
Just look at the module os.widget that you made, putting that many
asterisks makes the code hard to read. There is more asterisks in some
parts of the code then there is text.

In fact, I use naturaldocs syntax.
http://naturaldocs.org/documenting.html

Asterisks may be to much ok. i'll take time strip them out with more
traditionnal
/*
Title here
*/

(snip) POD is what most developers see all the time (snip)

I'm not a years developer (23 yo) but I never saw that, interesting,
but imao less human readable than NaturalDocs. Thanks anyway.

The next thing that would be really awesome is an explanation of all your dependencies,
does this module have to be a part of the whole os?

Everything is kernel/lib is part of the core yes. For example, the
menu uses os.menu, wich depends on os.widget. The taskbar will soon be
a widget too, so we can add more taskbar, move them, etc.

In my operating system Widget.Dialog is separated from the os namespace.

The namespace is really not consistent, true. My problem is that I
have a class model, for example, os.widget:
the "class" are stored in os.widget.init,
the runtime object are stored in os.widget.run
I'm not sure it's a good way doing it. Plus, some of the "class" are
stored before in the tree, like os.context or os.menu, because I don't
need to have runtime object directly accessible.
Another fix to come are windows, actually there is object model for
windows, there are only methods in the core (os) to create window
(createWindow, removeWindow), that have to be changed too.

Oh and a copyright notice saying 'Public Domain' and and author notice 'Rorist' will also help.

I was assuming the public domain doesn't require any credits, and that
was simplier. Because these credits can be stripped out by anyone with
that kind of "licence". But you are right, it will be easier to see
what is part of the core, and what is 3rd party library. I note.

If you do this then I hope to be able to try out the modules myself
(it is too hard to figure out right now).

Thanks for the time taken. Looking forward your answer on the above.

Bye