Wiki

[Lex Berezhny]

I think that it would be nice to have at least read-only access to the
wiki from the pyjs.org website with the consistent styling and
structure of the regular site (after Anthony does the redesign). This
way documentation, how-to guides, etc can be part of the website but
maintained in the wiki. If anyone wants to edit a wikipage the link
would take them to the github wiki.

When the pyjs.org site builds it will create:

http://pyjs.org/wiki/GettingStarted

Which will have the same styling as the rest of the pyjs.org website,
at the bottom there might be a link that would take the user to:

https://github.com/pyjs/pyjs/wiki/GettingStarted/_edit

Basically the point of all this would be to use the github wiki
infrustructure but still having the wiki tightly integrated into the
site with the site styling, etc.

Only downside is that at times the website will not be up to date with
the latest wiki pages, I don't think that's a big deal though.

Anyways, just a random thought.

- lex

[C Anthony Risinger]

We can actually pull the wiki live from github, and process clientside ... there are js libs for this at least.

There might be a way to pull a wiki page as preprocessed HTML to ... then it could just be styled.

Another option is to use github Jekyll facilities to buildout the wiki as a submodule of the site, or under its own CNAME.

I'll explore this more.

--

C Anthony

[Lex Berezhny]

I may be in the minority here but I would like to say that in my
opinion there is very little gained from having the pyjs.org website
built using pyjs. And a lot of downsides:

* complexity: which means it needs to be debugged, tested, etc.
* performance: pre-generated stand alone static HTML pages will load
much faster, especially if someone clicked to a directly link to the
pyjs.org website from somewhere else. and only cares about reading
that one page - why load all of the extra infrastructure?
* re-use: static HTML is much simpler to take off-line or to save as a
single page for later use. you shouldn't have to download a thousand
lines of javascript to read a single page of static FAQs.

Anyways, that's my two sense: I think using pyjs for realtively static
site is overkill, introduces more problems than it solves and I think
gives people the wrong impression of what pyjs is all about.

Just because we can doesn't mean we should. Better to use the right
tool for the job. Pyjs is great for interactive "applications", using
it for relatively static sites in my opinion is like driving a screw
by using a sledge hammer.

Am I the only one who feels that way?

- lex

[Charles Law]

I agree with this.  I also only like to use Pyjamas when the webpage has something interactive/dynamic going on.  If the page is pretty much static, writing a little HTML and Javascript isn't bad, and the page loads and runs much quicker.

[Apexi 200sx]

I agree, pyjs in my opinions niche is to help enable you to build complex interactive web applications (this is not to say you can;t build static apps though).

I think the actual pyjs website wold probably be better served with standard technologies for building static pages, with possible links/embedded carefully selected (the more polished?) examples apps.

This will enable updates to the pyjs website easier and less complex, at the end of the day the website should just be nice clean simple fast advertisement, with a big get started button, which then has a page with big buttons with choices of Windows or *nix for a simple download with everything to get started, and also a really easy to follow step by step getting started docco. - I am not sure how anybody else approaches a project but unless I REALLY need to use the tech i will have decided within a few mins whether to be bothered with something, in pyjs case it was only because i REALLY wanted to write web apps in python because i didn;t know javascript at all.

Links to nicely polished apps is good too.  I think in the past there has been on an emphasis on the example being the documentation, but it also seemed like there ended up being alot of them without any consistency of code, documentation, or how they were structured/built and this itself caused confusion, for me anyway with how things should be done.

[Pascal Chambon]

+1

A good CMS (django-cms ? FeinCMS ?) would do thee job without the hassle.
And if we integrate pyjs widgets on that site, it'll be a pure WIN: most
people want to see dynamic stuffs integrated into a "normal" site, not a
"I-did-it-all-by-myself-please-do-the-same" website that can't be of any
use for them.

Regards,
Pascal

Le 04/05/2012 19:19, Lex Berezhny a �crit :

[Lex Berezhny]

I think in this case the "CMS" is github wiki pages. They are
versioned, support almost every markup language under the sky and
should be relatively easy to integrate as input into a website build
process. And best of all it's already up and running and no
maintenance required.

We could have a couple of "special" wiki pages that the build process
understands as the home page or FAQ or whatever and renders them
differently, this could be as simple as just making those pages
available from a navigation menu, then the rest of the pages would
show up as plain regular wiki like pages and be referenced by the
"special" pages.

I think of the site as being essentially a dressed up and slightly
reconfigured version of the wiki to make it look more like a website
with some extra pages added and some special styling on specific pages
(maybe the FAQ page would be restyled significantly from the way it
looks in the Wiki, etc).

This way everyone can easily contribute to the site by just making
changes to the wiki and then a build process would run to turn the
wiki into a nice website.

The build process could be inclusive or exclusive. Only convert a
handful of special wiki pages and then link directly into the github
wiki for the rest (and lose the styling) or the build process could
convert the entire wiki and make it available with consistent styling
and navigation, then only edit links would take you to the github
wiki.

- lex

On Fri, May 4, 2012 at 1:30 PM, Pascal Chambon <pyth...@gmail.com> wrote:
> +1
>
> A good CMS (django-cms ? FeinCMS ?) would do thee job without the hassle.
> And if we integrate pyjs widgets on that site, it'll be a pure WIN: most
> people want to see dynamic stuffs integrated into a "normal" site, not a
> "I-did-it-all-by-myself-please-do-the-same" website that can't be of any use
> for them.
>
> Regards,
> Pascal
>

[joaojonesventura]

I think it would be better to start doing something right now, instead of planning too much.. Things are built step-by-step, and by planning to much, you will get information-paralysis.

There are github pages ready to go: start copying-pasting from the old pyjs site to the new site. The mailing list addresses are already wrong, must be corrected, etc.

I would recommend to open the process of edition to everyone, as changes to github wiki pages seem to be reversible, and any help is necessary. I'll give an example of the QT/Pyside wiki, which by the fact that everyone registered can edit the wiki, the Documentation grew really fast. I've even provided some articles like Setting up, some basic tutorials.. See http://qt-project.org/wiki/PySideDocumentation

Anthony and Lex, I suggest to start pushing things forward. Results will definitely appear after..


João Ventura

[Peter Bittner]

João,

> I think it would be better to start doing something right now, instead of
> planning too much.. Things are built step-by-step, and by planning to much,
> you will get information-paralysis.

No panic! Please. I get the point, and of course, you can start doing
something. Everyone should do by themselves.

> There are github pages ready to go: start copying-pasting from the old pyjs
> site to the new site. The mailing list addresses are already wrong, must be
> corrected, etc.

I don't get the point of copy-pasting. If content stays the same,
aren't there more important things to get going first? Check out the
Roadmap discussed today.

> I would recommend to open the process of edition to everyone, as changes to
> github wiki pages seem to be reversible, and any help is necessary. I'll
> give an example of the QT/Pyside wiki, which by the fact that everyone
> registered can edit the wiki, the Documentation grew really fast. I've even
> provided some articles like Setting up, some basic tutorials.. See
> http://qt-project.org/wiki/PySideDocumentation
>
> Anthony and Lex, I suggest to start pushing things forward. Results will
> definitely appear after..

I would suggest to get the processes stable that Anthony started to
implement - and was distracted by the rebellious nature of the mailing
list server.

I would also suggest to continue to push the 0.8.1 release of pyjs as
started by Luke - to prove that the new infrastructure doesn't mean
instability of the project.

The website is a thing to be done when the processes are in place and
stable. A reshaped website is not a big challenge, getting the
processes in place is. We have to get that right first.

Everyone who wants to help out and isn't sure what to do: please focus
on testing the examples. Look through the bug reports.

Hope that sounds okay for most of us,
Peter

[Michael Perkonigg]

Hello there,

I always felt unhappy how the examples are structured. I think an examples
page like the demo/example app from wxPython might look better.
We do have a nice and shiny web framework, why is the examples page
that plain?

Mike
--
Waage, Hahn, Haselbaum und Rabe

[C Anthony Risinger]

On Fri, May 4, 2012 at 7:21 PM, Michael Perkonigg <m.per...@ferret.at> wrote:
> Hello there,
>
> I always felt unhappy how the examples are structured. I think an examples
> page like the demo/example app from wxPython might look better.
> We do have a nice and shiny web framework, why is the examples page
> that plain?

yes awhile back i made it a bit more dynamic ... but there is much
room to improve. the examples would be a good place to have a real
pyjs app, in actual use, if we are to convert the site itself to
something simpler.

i do think it's important that pyjs host at least one app. on github
i alluded to this with a `learn.pyjs.org` ... this domain could
combine the the bookreader, examples, and similar.

perhaps someone out there has a nice framework or shell to start from?
hmmmm? i've heard thru the grapevine more than once that there are
some pretty cool apps out there ...

--

C Anthony

[Peter Bittner]

2012/5/5 C Anthony Risinger <ant...@xtfx.me>:

> On Fri, May 4, 2012 at 7:21 PM, Michael Perkonigg <m.per...@ferret.at> wrote:
>> Hello there,
>>
>> I always felt unhappy how the examples are structured. I think an examples
>> page like the demo/example app from wxPython might look better.
>> We do have a nice and shiny web framework, why is the examples page
>> that plain?

I can't find the almighty demo/example app from wxPython. Is this
something offline, not on their website? Can you provide a screenshot?

> yes awhile back i made it a bit more dynamic ... but there is much
> room to improve.  the examples would be a good place to have a real
> pyjs app, in actual use, if we are to convert the site itself to
> something simpler.
>
> i do think it's important that pyjs host at least one app.  on github
> i alluded to this with a `learn.pyjs.org` ... this domain could
> combine the the bookreader, examples, and similar.
>
> perhaps someone out there has a nice framework or shell to start from?
>  hmmmm? i've heard thru the grapevine more than once that there are
> some pretty cool apps out there ...

I'd love so see a real site nicely incorporating pyjs apps too.
Something that you can learn from.

In the meantime I thought clustering the existing examples would help
to think of a new structure:

== HELLO WORLD EXPERIMENTS ==
* ajaxlibtest
* anchor
* browserdetect
* clickablerootpanel
* clickoverride
* cssmesser
* getattr
* helloworld
* helloworldsplash
* maparea
* media
* navigate
* onclicktest
* svgtest
* timerdemo
== WIDGETS & CONTROLS ==
* addonsgallery
* builder
* controls
* datefield
* dnd
* flowpanel
* formpanel
* gridedit
* gridtest
* gwtcanvas
* kitchensink
* richtext
* splitpanel
* tabpanelwidget
* toggle
* treeitemcheckbox
* widgets
== SHOWROOM ==
* dynamictable
* employeeadmin
* funnysortedgridthing
* gcharttestapp
* gmaps
* mail
* shell
* showcase
* slideshow
* timesheet
== GAMES ==
* asteroids
* hangman
* lightout
* minesweeper
== 3RD PARTY LIBRARIES ==
* canvasprocessing
* jsimport
* jsobject
* raphael
== SERVER COMMUNICATION ==
* infohierarchy
* jsonrpc
* misc (djangotasks, djangowanted, djangoweb, flaskexamples,
flowplayer, gaedjangononrelpuremvcblog, scoping, simplewiki,
swfupload)
* picasaweb
* uploader
* xmldoc
== TESTING, LOGGING, DEBUGGING ==
* libtest
* uitest
== DEPRECATED ==
* deprecated (gears, pywebgtkbuilder)

Each example should provide a (good) title, a short explanation, a
working demo (of course!), and an easy way to see the full source
code. The "Showcase" is a good - though unstyled - example. (GWT's
Showcase looks a little bit less old-fashioned:
https://developers.google.com/web-toolkit/examples/)

Shall we use a Wiki page to discuss this, or open a bug report and put this in?

Peter

[Gustaf Nilsson]

I quite like the showcase as a demo for pyjamas. Particularly because
it shows the source code right there with the results so you instantly
can connect the dots.
I started doing a little work on adding more features to it, but didnt
get very far.

--
■ ■ ■ ■ ■ ■ ■ ■ ■ ■

[Peter Bittner]

Gustaf,

2012/5/5 Gustaf Nilsson:

> I quite like the showcase as a demo for pyjamas. Particularly because
> it shows the source code right there with the results so you instantly
> can connect the dots.
> I started doing a little work on adding more features to it, but didnt
> get very far.

_All_ examples should have a short introduction along with the source
code - similar to the Showcase!

I'm just wondering about how an application could look like that does
that generically...

Peter

[Michael Perkonigg]

On 5 May 2012 at 19:36, Peter Bittner wrote:

> I can't find the almighty demo/example app from wxPython. Is this
> something offline, not on their website? Can you provide a screenshot?

I uploaded them to PicPaste, so they will be gone after 14. May. Tell me if
you want them posted here (approx. 120kB each) or sent them to you
personally.

http://picpaste.com/Clipboard01-JTkywWos.jpg
http://picpaste.com/Clipboard02-pHbhKG4a.jpg
http://picpaste.com/Clipboard03-P61h1NmA.jpg
http://picpaste.com/Clipboard04-dmHLU9nQ.jpg

[Peter Bittner]

Thanks Michael!

2012/5/8 Michael Perkonigg <m.per...@ferret.at>:

We could use a similar layout for an almighty demos/examples site:

- tree => left, tabbed_pane => center
- Content in the tree could be grouped/clustered (e.g. as I proposed earlier)
- After all similar to what the Showcase already is, just with a
tabbed pane to clean up a bit

Anyone ready to write such a website or application? (In CGI-Python?
generated HTML from Pyhon? with framework <XYZ>? Pyjs?)
Suggestions?

Peter

[Kees Bos]

pyjs of course :-)

The demo tab would be a iframe with the demo loaded (It would probably
too complex / slow to load all together and create one big monstrous
app.

[Rich Newpol]

Actually, I have found that most non-trivial pyjs apps load a lot of
the same code anyway, so splitting the demos into actual separate apps
may not make it more usable (i.e. faster loading). Probably better
just to make it one large app, that loads with a "loading" progress
indicator (this was discussed some time ago by folks in these
forums)..

For Assurity, we have one pretty complex app with lost of widgets, so
we run a code compressor on the pyjs output and it actually loads in a
reasonable amount of time (about 5-6 seconds depending on
connection)...

R

[Gustaf Nilsson]

yeah makes sense.
say a small app takes 1mb and a big one takes 2mb (looking at my own
projects for reference). that means you will either load 2mb once or
1mb ten times as you flick through the examples...

--
■ ■ ■ ■ ■ ■ ■ ■ ■ ■