Cappuccino 1.0 Roadmap

[Francisco Tolmasky]

Now that 0.8 is out the door we're going to be focusing on putting
together a roadmap for 1.0. I'd like to first have a discussion as to
what features everyone thinks are must haves, and then from that list
create a roadmap we can all work together towards. I've included below
what we believe to be some obvious features, but none of these have to
necessarily make the final list (in fact it would be surprising if all
of them made the final list).

1. Better theme support - support for CSS-style cascading, and a
generally easier way to put together themes
2. Build out remaining Aristo widgets - (color picker, stepper view,
calendar, tabs, etc -- all themable of course)
3. Documentation - If you caught my presentation on Socratic at JSConf
you'll know that we're currently working on a new tool to provide wiki-
based documentation to the Cappuccino project.
4. Bindings support (probably building off the existing bindings
branch).
5. Performance - Coupled with a tool that can accurately report
performance, it would be nice to come up with some solid targets for
the performance we'd want for 1.0
6. TextView (and better text support in general)
7. CoreData/LocalStorage/Modeling stuff in general
8. Comprehensive tests

So please comment on what is most important to you and add anything I
may have left out.

Francisco

--
You received this message because you are subscribed to the Google Groups "Cappuccino & Objective-J" group.
To post to this group, send email to objec...@googlegroups.com.
To unsubscribe from this group, send email to objectivej+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/objectivej?hl=en.

[Justin Freitag]

Awesome - 5, 6, 7 & 8 are on my wanted list.

[Layton Duncan]

Performance and better multiline editable text views are my to big wish list items.

Layton

[Saikat Chakrabarti]

Off the top of my head (some are repeats of what's on the list - just stating what I find most important):

1. Something like Selenium recorder for Cappuccino apps. Barista is part of the way there. Tom had something that records based on pixel coordinates, but that is still too fragile.
2. TextViews
3. A better knowledge-base. I don't know a lot about socratic, but I think it handles mostly code documentation? But I was really impressed with how fleshed out, for example, the Node project's wiki is - it's a one-stop place for newbies and everyone to see what is out there, get tutorials, etc.
4. Performance
5. More tests in the framework, especially around CPTextField.
6. Text drawing (possibly related to 2).

I'll add on if I think of more. Awesome to see that 1.0 is ahead.

- Saikat

[Derek Hammer]

I strongly second Saikat's #3. We need a way to leverage the active community around Cappuccino.

This is a bit more controversial, but I think we need to start pushing a testing culture around Cappuccino. This means flaunting the testing tools around Cappuccino (OJUnit, OJSpec, OJMoq, OJAutotest, OJCov, etc.) and make them part of the standard Cappuccino experience.

[Justin Freitag]

I'm not a big fan of documentation outside of the code itself. Well written tested code "is" well documented code.

Justin.

[John C. Fox]

Hi Guys:

This probably falls under the general rubric of performance, but I'd love to see further work on reducing the footprint of an app: for example, stripping out unused images in the AppKit image sprites. 

John

On Apr 22, 2010, at 4:39 PM, Francisco Tolmasky wrote:

---

John C. Fox 

Founder 

GroupSmarts, LLC 

MemoryMiner - "Record memories...tell stories"

http://www.memoryminer.com

[Justin Freitag]

I'm not a big fan of documentation outside of the code itself. Well written tested code "is" well documented code.

Justin.

On 23/04/2010, at 9:59 AM, Derek Hammer wrote:

[Antonio Salazar Cardozo]

For an experienced developer with plenty of time, perhaps. As fun as
it is to go code-diving whenever there is a problem, it's
extraordinarily inefficient compare to easily browseable API docs
during active dev and tutorials/examples when getting started.
Antonio

On Apr 22, 2010, at 20:03, Justin Freitag <justin....@gmail.com>
wrote:

[Saikat Chakrabarti]

Sure, but I mean something to aggregate tutorials, relevant blog posts, and somewhere to see what other projects/libraries exist, what the state of these is, etc.  

[Brad Hutchins]

Not sure if performance can be really increased until JS interpreters go to JS LLVMs.

[Mason]

I think better text support (multiline editable text, and rich text
display) is crucial, because it is something that any plain old-school
HTML web app can do reasonably well, and customers/users expect that
capability.

And, it's just a very fundamental part of so many kinds of
applications. So I think it's a key feature to have before attaching
the "1.0" label.

On Apr 23, 8:39 am, Francisco Tolmasky <franci...@280north.com> wrote:
> Now that 0.8 is out the door we're going to be focusing on putting
> together a roadmap for 1.0. I'd like to first have a discussion as to
> what features everyone thinks are must haves, and then from that list
> create a roadmap we can all work together towards. I've included below
> what we believe to be some obvious features, but none of these have to
> necessarily make the final list (in fact it would be surprising if all
> of them made the final list).

[Derek Hammer]

I'm a big believer in self documenting code.

However, large frameworks and new languages need tutorials and API docs in order for being to be able to navigate around.

[Mike Fellows]

> 3. Documentation - If you caught my presentation on Socratic at JSConf
> you'll know that we're currently working on a new tool to provide wiki-
> based documentation to the Cappuccino project.

I would put this one at number one by a long shot. Having just spent
a couple of months learning Cappuccino/Objective-J the documentation
is far too sparse. The API just needs to be documented with a line or
two for each method explaining roughly what it does and/or whether or
not it's been fully implemented yet.

I don't have any problem with the structure of the existing API docs.
My suggestion would be to start working on a Wiki like thing as a
second step after bringing the existing docs up to date.

That being said, thanks for all the good stuff in Cappuccino so far.

Regards,
Mike

[Paul Baumgart]

Socratic isn't meant to replace code documentation. It's meant to
replace API documentation, and add better functionality on top of it.
The objective is to create a more maintainable and more flexible
version of http://cappuccino.org/learn/documentation/. Also, it needs
to be easy to integrate other useful information, like bug reports,
demos, tutorials, etc. with the relevant sections of the API docs.

Maintainability is the most important point here. It needs to be
really simple to keep the docs up-to-date as Cappuccino evolves. And
the system should do as much of that automatically as possible.

Since the user-facing portion of Socratic will basically be a wiki, it
should be possible to grow it into a fully-fledged knowledge base.

Anyone interested in discussing the topic in more detail, feel free to
shoot me an email. :-)

Paul

[Paul Baumgart]

One thing that occurred to me after I wrote that:

Socratic obviously isn't ready right now. I'm working on fixing that,
but I don't want it to block any efforts to improve documentation
*right now*.

We have the GitHub wiki. If enough folks feel like that doesn't cut it
to set up something else, that's fine too.

Either way, those docs can be imported once Socratic is up and
running, probably with only minor manual effort. So don't feel like
anything's holding you back.

Paul

[陈天舟]

2, 3, 5, 6 are on my wish list.

Besides, I would like to see there is some enhancement to objective-J. Such as @protocol keyword.

I must be very excited when Cappuccino 1.0 comes out.


Cheers
Tianzhou

2010/4/23 Paul Baumgart <pa...@baumgart.us>

[Randy Luecke]

So, with the 0.8 release I think it's safe to say we have the most
kick ass tableview on the web, but it's not done. Performance is key
with 1.0. We need to make sure everything that can be cached is
cached, in addition I don't think there is any reason to not finish
implementing the remaining features of NSTableView (group rows,
variable row heights, reorderable columns, etc) from there we can add
themeing support on top of the new themeing engine.

I'm aware that all of the before mentioned features exist in different
forks but performance is key, they al must work together and they must
be FAST. The tableview could also use an audit of the code. The class
is massive, so if we can reduce the amount of code that will make the
download smaller as well as reducing redundency.

On Apr 22, 9:35 pm, Paul Baumgart <p...@baumgart.us> wrote:
> One thing that occurred to me after I wrote that:
>
> Socratic obviously isn't ready right now. I'm working on fixing that,
> but I don't want it to block any efforts to improve documentation
> *right now*.
>
> We have the GitHub wiki. If enough folks feel like that doesn't cut it
> to set up something else, that's fine too.
>
> Either way, those docs can be imported once Socratic is up and
> running, probably with only minor manual effort. So don't feel like
> anything's holding you back.
>
> Paul
>
>
>
>
>
> On Thu, Apr 22, 2010 at 6:14 PM, Paul Baumgart <p...@baumgart.us> wrote:
> > Socratic isn't meant to replace code documentation. It's meant to
> > replace API documentation, and add better functionality on top of it.
> > The objective is to create a more maintainable and more flexible

> > version ofhttp://cappuccino.org/learn/documentation/. Also, it needs

> > to be easy to integrate other useful information, like bug reports,
> > demos, tutorials, etc. with the relevant sections of the API docs.
>
> > Maintainability is the most important point here. It needs to be
> > really simple to keep the docs up-to-date as Cappuccino evolves. And
> > the system should do as much of that automatically as possible.
>
> > Since the user-facing portion of Socratic will basically be a wiki, it
> > should be possible to grow it into a fully-fledged knowledge base.
>
> > Anyone interested in discussing the topic in more detail, feel free to
> > shoot me an email. :-)
>
> > Paul
>

> >>>>>> For more options, visit this group athttp://groups.google.com/group/objectivej?hl=en.

>
> >>>>> --
> >>>>> You received this message because you are subscribed to the Google Groups "Cappuccino & Objective-J" group.
> >>>>> To post to this group, send email to objec...@googlegroups.com.
> >>>>> To unsubscribe from this group, send email to objectivej+...@googlegroups.com.

> >>>>> For more options, visit this group athttp://groups.google.com/group/objectivej?hl=en.

>
> >>>> --
> >>>> You received this message because you are subscribed to the Google Groups "Cappuccino & Objective-J" group.
> >>>> To post to this group, send email to objec...@googlegroups.com.
> >>>> To unsubscribe from this group, send email to objectivej+...@googlegroups.com.

> >>>> For more options, visit this group athttp://groups.google.com/group/objectivej?hl=en.

>
> >>> --
> >>> You received this message because you are subscribed to the Google Groups "Cappuccino & Objective-J" group.
> >>> To post to this group, send email to objec...@googlegroups.com.
> >>> To unsubscribe from this group, send email to objectivej+...@googlegroups.com.

> >>> For more options, visit this group athttp://groups.google.com/group/objectivej?hl=en.

>
> >> --
> >> You received this message because you are subscribed to the Google Groups "Cappuccino & Objective-J" group.
> >> To post to this group, send email to objec...@googlegroups.com.
> >> To unsubscribe from this group, send email to objectivej+...@googlegroups.com.

> >> For more options, visit this group athttp://groups.google.com/group/objectivej?hl=en.

>
> --
> You received this message because you are subscribed to the Google Groups "Cappuccino & Objective-J" group.
> To post to this group, send email to objec...@googlegroups.com.
> To unsubscribe from this group, send email to objectivej+...@googlegroups.com.

> For more options, visit this group athttp://groups.google.com/group/objectivej?hl=en.

[Alexander Ljungberg]

> 4. Bindings support (probably building off the existing bindings
> branch).

Definitely build off the existing bindings branch. Bindings are
basically functional already with the addition of a few patches.

[Dimitris Tsitses]

I posted a comment before about CPTableView which doesn't seem to show
for some reason. Anyhow, a bug free and fully featured table is at the
top of my wish list.

[Dimitris Tsitses]

Would love to see a more bug-free and feature complete CPTableView.

We are working on a fairly complex app with all sorts of tables, and
issues hit from several angles. With other components it's ok to dig
in the code and tweak things when required, but patching CPTableView
routinely on an individual basis hasn't been very realistic so far.
Outside contributions hardly ever seem to make it into the mainline,
and it's almost guaranteed (at least historically) that future
releases will break local patches. As a result, it has often been a
show stopper for us.

[Jesse Armand]

Something that would be nice to have, and I don't know if it does
exist in the current version, or whether it would be feasible for 1.0.

iPhone OS user interface support, so Cappuccino could be used to build
iPhone or iPad web apps.
If AppKit could accommodate iPhone OS UI, that would be great too.

[Jake Mallory]

Ba! Well written code certainly helps but it shouldn't be the only doc
for something as complex as a framework. I'm totally new to cocoa and
obj-c/j and have spent plenty of time in the source trying to figure
out what can be done based on Apple's Cocoa documentation. This
doesn't add value to my dev cycle. I'd refer you to the documentation
for Ruby on Rails. It's not so complete that there is no need for
tutorials, blog articles and other community contributions but it does
an excellent job of explaining concepts and usage. Reduce the barrier
to entry. This goes along way for adoption which will lead to more
contributions from the community. That is a good cyclical dependency
to have.

> >>> For more options, visit this group athttp://groups.google.com/group/objectivej?hl=en.

>
> >> --
> >> You received this message because you are subscribed to the Google Groups "Cappuccino & Objective-J" group.
> >> To post to this group, send email to objec...@googlegroups.com.
> >> To unsubscribe from this group, send email to objectivej+...@googlegroups.com.

> >> For more options, visit this group athttp://groups.google.com/group/objectivej?hl=en.

>
> > --
> > You received this message because you are subscribed to the Google Groups "Cappuccino & Objective-J" group.
> > To post to this group, send email to objec...@googlegroups.com.
> > To unsubscribe from this group, send email to objectivej+...@googlegroups.com.

> > For more options, visit this group athttp://groups.google.com/group/objectivej?hl=en.

>
> --
> You received this message because you are subscribed to the Google Groups "Cappuccino & Objective-J" group.
> To post to this group, send email to objec...@googlegroups.com.
> To unsubscribe from this group, send email to objectivej+...@googlegroups.com.

> For more options, visit this group athttp://groups.google.com/group/objectivej?hl=en.

[Jesse Armand]

Jake,

I think Cappuccino will reduce the barrier to entry for native apps or
cocoa developers.
Not most web developers heavily invested in another web frameworks.

[Ross Boucher]

Just to put this question to rest, documentation is absolutely a core concern for us. We're not here to capture 100% of the Cocoa dev audience and nobody else.

[Ignacio Cases]

Following Francisco's list, I would consider essential for a 1.0 release

3. Documentation 

5. Performance 

6. TextView (and better text support in general)

Very important

8. Comprehensive tests

And really nice to have

4. Bindings support

7. CoreData/LocalStorage/Modeling

Cheers,

-Ignacio

[Johannes Fahrenkrug]

Hi everybody,

there are two things that I would really like to see in a 1.0 release:
Firstly, better use of modern browser features if available. for
example, some of the core animation stuff will perform much much
better if it would take advantage of CSS3 transforms.
Secondly, it would be nice to have a clean API to access the DOM. I
know, I know: it's a capital offense to access the DOM ;-) but for
some frameworks, wrappers or additions you can get around accessing
the DOM. being able to do that in a defined way that does not use
private APIs would be nice.

And lastly, but this is just a question, what about a canvas
renderer? I know there were talks in the past about providing not
only a DOM renderer, but also a canvas-based one. is that still the
plan?

Either way, it is very exciting to see how fast this wonderful project
moves forward!

Keep up the good work!


- Johannes

[Houston]

Performance is number 1 on my list.

- Adam

[Macsig]

1. More documentation
2. Integration with Cucumber


Thanks guys

[JesusPerez]

Definitively I am agree performance is the first.

Coming from web-development rather than COCOA, to do simple things
does not look very easy when you get into Cappuccino. So doc it will
be very helpful I like to use wiki for tracking projects ... let see
what Socratic can offer. A way to collect most of the thing around
Cappuccino will attract users and developers and to help to promote
the concept of objective-j. At this point I include graphics (canvas),
animations, etc.

TextView should be improved urgently, please.

For the look & feel 1 and 2 would be at my top priorities, support of
CSS will open a very interesting door specially with HTML5 ....
Theme ... theme !!!!

Finally 4 and 7 will be interesting.

I do not want to forget mobile devices, iPad, etc we should develop
not only for macs with cocoa around the web and browsers we should be
portables and give a fun and attractive experience for a user that
usually do not have patient neither time.

So to recap ... Find out what is at the top of your list ?

How we look ? How fast we do it ? What we do ? How we do it ? Do it
secure ? To keep performance ? To be known as Framework ?
Do we need to be a COCOA shadow for the Web ?
How to promote a community to inspire our developments and
contributions ?

I vote for a community working for performance on an attractive
environment.

Let sing a Queen song ... "I want it all ... I want it now !!!! "

Regards,
-Jesus

[klaaspieter]

Top 1.0 tasks for me are bindings and improving the table view.

The current bindings branch is pretty functional from what I can see
the things left to do are updating (and testing) all the controls to
support their bindings.

Like Randy said already, the tableview is awesome, but like Dimitris
mentioned there's also a lot of room for improvement. Issues with the
current tableview are mainly focused on datacells and caching. I've
already started a discussion about this here:
http://github.com/280north/cappuccino/issues#issue/509.

Something else that needs focus in my opinion are the extensibility of
Cappuccino classes. Almost all classes access instance variables
directly in stead of using accessors. This makes extending those
classes hard and also breaks KVO.

For example the CPCollectionView should just be able to override
numberOfRows to return something else, this means that the CPTableView
needs to call [self numberOfRows] whenever it needs to know how many
rows it has. The method should return _numberOfRows if defined
otherwise ask the dataSource for the number of rows (the bindings
branch has a correct implementation I believe).

The CPCollectionView -> CPTableView behavior is just an example, the
problem explained exists in most Cappuccino classes which makes it
hard to extend them.

Some other concern of mine is the amount of patches that actually land
on the trunk. Like Dimitris mentioned, a lot of bugs are fixed but
never actually land on the trunk because of various reasons. Currently
the patch review process resembles Apple's App Store review process in
that there are no guidelines. I think we can all make it easier for
the committers if we make sure our patches conform to a standard set
of guidelines. This is a completely different discussion, but having a
clear set of guidelines might automatically fix the lack of
documentation and tests. Sample guidelines could be:

1. Your patch is confined in one commit so it can be easily cherry-
picked or, if it's not a single commit, is on a clean master branch.
(No other changes except for the problem you are trying to fix)
2. Your patch doesn't break any current tests and contains proper
tests where applicable (fixing the testing issue)
3. Your patch fully documents any new methods (fixing the
documentation issue)
4. Optionally, your patch may not degrade performance in any way

Having these guidelines available in a public and easy to find place
gives committers a place to point to when a faulty patch is submitted.
It also makes sure that adding changes into the trunk is just a matter
of seeing if it's a valid patch, running the (performance) tests and
actually committing it. Of course, I'm not a committer so they
actually might have more and or different demands.

On Apr 23, 7:58 am, Ross Boucher <rbouc...@gmail.com> wrote:

[Daniel Stolzenberg]

My top-priority features for Cappuccino 1.0:

6. CPTextView
@protocol and conformsToProtocol: within Objective-J (Tianzhou
mentioned this)

Nice to have but not really high priority:

4. Bindings
7. CoreData

I`d prefer a soon-to-come 1.0 enhanced with top-priority "API-only
features" identified in this discussion over a delayed release
adressing complex concerns like Documentation/KnowledgeBase, Testing
and Performance.


But besides this discussion: Thank you Cappuccino for being truly
"cocoa for the web"!!! I really appreciate the fact, that without this
level of abstraction provided by a familiar and mature API a web-dev-
newbie link me would never have been able to develop any complex RIA
entirely based on standards! It`s like every browser has become a Mac!

Daniel

[Jerod Santo]

I'd just like to add my +1 to pretty much everything Klaas said.

Jerod Santo
http://jerodsanto.net

[Emmanuel Maillard]

I think that Internationalization and Localization should be consider essential for a 1.0 release.
A complete text handling and many other features will depend on Locale settings.

Emmanuel

[fisk]

1. I would like to see a real parser. I have a fully functional
LALR(1) parser generator and the grammar for Objective-J here:
http://github.com/fisk/objective-j-parser and I suggest integrating it
somehow. The advantage of having a real parser is that the syntax
awareness allows you to for instance have C-style pointers, which my
parser does currently, which makes life easier when sending
references.
2. A Ruby version of cappuccino like MacRuby but for Cappuccino. Could
be done with the same parser generator as stated above.
3. A new semi-real text system. With a real parser, it would be easy
to build an AST to make text editing views with syntax awareness.

Yeah so basically, a new real parser.

Erik

> For more options, visit this group athttp://groups.google.com/group/objectivej?hl=en.

[cacaodev]

1. Core Animation CAAnimation, CATransition using cssAnimations in
webkit
2. Better text view and text completion. Text drawing in canvas (done)
and VML
3. Core Data
4. Bindings
5. CPUserDefaults: local defaults with localStorage or cookies /
online defaults in conjunction with a session/auth manager.
6. CPDatePicker with 2 modes: textfield and calendar
7. CPTrackingArea
8. Better theming and guidelines when implementing themes in the
framework. We need to know what will be themable or not and a way to
specify attributes that are not yet available in the theme bundle.

For later: a CPPopoverController ala iPad. Browser wide alerts ala
google chrome.

And I agree with the previous contributors: localization, CPLocale and
a support for references in the compiler.

[Tys von Gaza]

+1. Out of all the items listed, getting good test coverage on
Cappuccino should be number one. This is the largest code debt that
Cappuccino currently has and will allow for the faster innovation in
the future once it is paid off.

Tys

On Apr 22, 5:59 pm, Derek Hammer <derek.r.ham...@gmail.com> wrote:
> I strongly second Saikat's #3. We need a way to leverage the active community around Cappuccino.
>
> This is a bit more controversial, but I think we need to start pushing a testing culture around Cappuccino. This means flaunting the testing tools around Cappuccino (OJUnit, OJSpec, OJMoq, OJAutotest, OJCov, etc.) and make them part of the standard Cappuccino experience.
>
> On Apr 22, 2010, at 7:54 PM, Saikat Chakrabarti wrote:
>
>
>
>
>
> > Off the top of my head (some are repeats of what's on the list - just stating what I find most important):
>
> > 1. Something like Selenium recorder for Cappuccino apps.  Barista is part of the way there. Tom had something that records based on pixel coordinates, but that is still too fragile.
> > 2. TextViews
> > 3. A better knowledge-base.  I don't know a lot about socratic, but I think it handles mostly code documentation?  But I was really impressed with how fleshed out, for example, the Node project's wiki is - it's a one-stop place for newbies and everyone to see what is out there, get tutorials, etc.  
> > 4. Performance
> > 5. More tests in the framework, especially around CPTextField.
> > 6. Text drawing (possibly related to 2).
>
> > I'll add on if I think of more.  Awesome to see that 1.0 is ahead.
>
> > - Saikat
>

[Jake Mallory]

Jesse,

I think that the adoption of cappuccino, extJS, sproutcore, ukit, gwt
and JavaScriptMVC (might be more) proves that plenty of web devs are
willing to learn a new paradigm and framework. Objective-J certainly
adds a barrier but it isn't that difficult and plenty will be willing
to learn it if they feel there is greater value in this framework.

It has been mentioned but functional/integration testing is a bit
difficult at the moment. Not really sure what can be done about this,
but hopefully someone smart comes up with a good solution. Naturally
I'd prefer a cucumber solution.

Go get 'em

[Zach]

I'd like to put another notch under the multiline text view; this is
definitely my greatest concern. LPKit's is a great start, but I don't
think there is anything like sizeToFit to make the height fit the text
inside of it, and the editable version is a bit wonky. Really excited
to see what you guys come up with.

On Apr 22, 8:27 pm, Mason <mason-goo...@fivespeed.com> wrote:
> I think better text support (multiline editable text, and rich text
> display) is crucial, because it is something that any plain old-school
> HTML web app can do reasonably well, and customers/users expect that
> capability.
>
> And, it's just a very fundamental part of so many kinds of
> applications. So I think it's a key feature to have before attaching
> the "1.0" label.

>
> On Apr 23, 8:39 am, Francisco Tolmasky <franci...@280north.com> wrote:
>
> > Now that 0.8 is out the door we're going to be focusing on putting
> > together a roadmap for 1.0. I'd like to first have a discussion as to
> > what features everyone thinks are must haves, and then from that list
> > create a roadmap we can all work together towards. I've included below
> > what we believe to be some obvious features, but none of these have to
> > necessarily make the final list (in fact it would be surprising if all
> > of them made the final list).
>

[alosii]

I was going to say finishing CPSound. But that would be too selfish.
So I'm gonna vote for adding:

1.- TextView
2.- CoreData
3.- CPSound

[Tom Robinson]

On Apr 23, 2010, at 3:44 AM, fisk wrote:

> 1. I would like to see a real parser. I have a fully functional
> LALR(1) parser generator and the grammar for Objective-J here:
> http://github.com/fisk/objective-j-parser and I suggest integrating it
> somehow. The advantage of having a real parser is that the syntax
> awareness allows you to for instance have C-style pointers, which my
> parser does currently, which makes life easier when sending
> references.

I'd like to see this too at some point.

Optional static typing is one of the potential features enabled by having our own language. Ideally we'd have Cappuccino itself taking advantage of static typing to improve stability/safety (possibly performance?), and app developers opting in if that's their cup of tea. It's unlikely to make it in by 1.0 though.

> 2. A Ruby version of cappuccino like MacRuby but for Cappuccino. Could
> be done with the same parser generator as stated above.

There are actually two partial implementations of this, both aptly called "CappRuby":

http://github.com/adambeynon/cappruby
http://github.com/tlrobinson/cappruby

Mine (tlrobinson) is really just a proof of concept, and only supports a subset of Ruby. I haven't evaluated adambeynon's in depth but it looks promising.


I'm also interested in providing a pure JavaScript "binding" to Cappuccino. There obviously are features of Objective-J which simply aren't possible in JavaScript (without ugly hacks, at least), but if we can get 90% of the way it might be useful to those who (usually irrationally) refuse to learn our small extension to JavaScript ;)

I'd like to gauge interest in this, so contact me if you're interested.

-tom

[Jérôme Denanot]

I just started work on this a few day ago once I realized it would help newcomers. No code yet just notes), however the idea should be easy to implemement.

2010/4/24 Tom Robinson <tlrob...@gmail.com>

[Jérôme Denanot]

Some ideas (some of those are redondant with previous posts) :

- complete the texfield for large text editing (with attributes) : fonts editings (glyphs) may not have to be as evolved as in Cococa, as we can finally perhaps rely on (new/future) features provided by the browser ?

- latest features to add to tableView : columns reordering, in-line editing (perhaps with some nice effect - for example zooming through core animation or another -:), better documenting to make contributing easier (there is still a synchronization problem I encounter when sorting on Firefox - transient value, at least when using cp2javaws -, and it is difficult to fix due to some obscure parts. I agree however it didn"t stop Randy from doing his great contributing).

- consolidate all informations/tutorials from many sites about cappuccino, and also informations from this group : sorted by subject and relevance with Cappuccino versions (some tips are not relevant anymore). Also list all production applications (with screenshots) based on Cappuccino.

- provide a syntax verifier for external (non Altas) code editors (Coda, etc.)

- provide a way for coding in JS (for newcomers, even if in the end they will probably discover the power of objj syntax, that is finally easy and more readable). I'm working on this feature.

- make it easier to modify core classes without having to recompile the whole core frameworks (even if fast now - 5 mn with JavascriptCore on my old G4). Would make contributing easier.

- add more tests, as the framework is now huge, and regressions are then more likely to happen (hopefully you do a stunning work... however it would'nt be as easy to ensure with more and more contributors - me first :-)).

- open Atlas by providing a plugin architecture, alla Eclipse plugins.

- provide iPhone/iPad target (as planned initially for Atlas)

- add some of a theme editor (in Atlas ?)

- add some UML/MDA diagrams in Atlas (would be complementary to the acutal layout management)

- add (basic) wrappers for those now common features : WebSockets, WebGL. And add hardware accelerating to Core Animation implementation by using new accelerated Canvas tag and/or WebGL, or more likely CSS transitions/transforms (when available).

2010/4/23 Francisco Tolmasky <fran...@280north.com>

Now that 0.8 is out the door we're going to be focusing on putting
together a roadmap for 1.0. I'd like to first have a discussion as to
what features everyone thinks are must haves, and then from that list
create a roadmap we can all work together towards. I've included below
what we believe to be some obvious features, but none of these have to
necessarily make the final list (in fact it would be surprising if all
of them made the final list).

1. Better theme support - support for CSS-style cascading, and a
generally easier way to put together themes
2. Build out remaining Aristo widgets - (color picker, stepper view,
calendar, tabs, etc -- all themable of course)
3. Documentation - If you caught my presentation on Socratic at JSConf
you'll know that we're currently working on a new tool to provide wiki-
based documentation to the Cappuccino project.
4. Bindings support (probably building off the existing bindings
branch).
5. Performance - Coupled with a tool that can accurately report
performance, it would be nice to come up with some solid targets for
the performance we'd want for 1.0
6. TextView (and better text support in general)
7. CoreData/LocalStorage/Modeling stuff in general
8. Comprehensive tests

So please comment on what is most important to you and add anything I
may have left out.

Francisco

--
You received this message because you are subscribed to the Google Groups "Cappuccino & Objective-J" group.
To post to this group, send email to objec...@googlegroups.com.
To unsubscribe from this group, send email to objectivej+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/objectivej?hl=en.