[wxpython-users] How to incorporate splitter windows in boa constructor
David Lyon
Hi all,
I'm in Boa Constructor.
I press the help button and I get C++ code.... I don't understand C++ code.
How can I find out how to use the Splitterwindow?
I've looked at the wxpython examples and they down't work within boa
constructor...
How do I use these things? I have a very simple app...
(un)Help as follows:
wxSplitterWindow overview
Classes: wxSplitterWindow
The following screenshot shows the appearance of a splitter window with a
horizontal split.
The style wxSP_3D has been used to show a 3D border and 3D sash.
Example
Example
The following fragment shows how to create a splitter window, creating two
subwindows and hiding one of them.
splitter = new wxSplitterWindow(this, -1, wxPoint(0, 0), wxSize(400,
400), wxSP_3D);
leftWindow = new MyWindow(splitter);
leftWindow->SetScrollbars(20, 20, 50, 50);
rightWindow = new MyWindow(splitter);
rightWindow->SetScrollbars(20, 20, 50, 50);
rightWindow->Show(false);
splitter->Initialize(leftWindow);
// Set this to prevent unsplitting
// splitter->SetMinimumPaneSize(20);
The next fragment shows how the splitter window can be manipulated after
creation.
void MyFrame::OnSplitVertical(wxCommandEvent& event)
{
if ( splitter->IsSplit() )
splitter->Unsplit();
leftWindow->Show(true);
rightWindow->Show(true);
splitter->SplitVertically( leftWindow, rightWindow );
}
void MyFrame::OnSplitHorizontal(wxCommandEvent& event)
{
if ( splitter->IsSplit() )
splitter->Unsplit();
leftWindow->Show(true);
rightWindow->Show(true);
splitter->SplitHorizontally( leftWindow, rightWindow );
}
void MyFrame::OnUnsplit(wxCommandEvent& event)
{
if ( splitter->IsSplit() )
splitter->Unsplit();
}
Mike Driscoll
> Dear Pythoners,
>
> I've got two questions for you since I need help to improve my GUI
> application.
>
> I've just finished writing a basic GUI interface for my former python
> application and it works!
> However, my old application writes info and outputs into logs (text
> files).
>
> Can you suggest me a way (steps?) to restructure my application so
> that I can send relevant information to a wx window (for example, a
> frame with some auto-updating counters and a nice progress bar)?
>
> Basically, I have the following:
>
> a frame with a control list of files (added via a File chooser) and a
> start button.
>
> ---> The start button triggers the execution of a method that call
> some methods of my older class. These methods write information in a
> log file.
>
> How can I grab updated infos from older class' methods during their
> execution?
>
>
> Question 2 is:
>
> I would like to abort the process. How can I stop the execution of a
> method so that the control comes back to the main window?
>
>
> Thanks a lot in any case!
>
>
In addition to what Anthony suggested, I recommend checking out the
demo. There is a couple of widgets in there that you could use for the
progress bar and some examples of threading as well.
-------------------
Mike Driscoll
Blog: http://blog.pythonlibrary.org
__________ Information from ESET NOD32 Antivirus, version of virus signature database 4101 (20090525) __________
The message was checked by ESET NOD32 Antivirus.
Domenico Nappo
Anthony Floyd
<domenic...@gmail.com> wrote:
> Dear Pythoners,
>
> I've got two questions for you since I need help to improve my GUI
> application.
>
> I've just finished writing a basic GUI interface for my former python
> application and it works!
> However, my old application writes info and outputs into logs (text files).
>
> Can you suggest me a way (steps?) to restructure my application so that I
> can send relevant information to a wx window (for example, a frame with some
> auto-updating counters and a nice progress bar)?
>
> Basically, I have the following:
>
> a frame with a control list of files (added via a File chooser) and a start
> button.
>
> ---> The start button triggers the execution of a method that call some
> methods of my older class. These methods write information in a log file.
>
> How can I grab updated infos from older class' methods during their
> execution?
Check out pubsub. It allows you to pass messages back and forth
between the GUI and the engine pretty effortlessly.
http://wiki.wxpython.org/PubSub
>
> Question 2 is:
>
> I would like to abort the process. How can I stop the execution of a method
> so that the control comes back to the main window?
Also from the Wiki, see Long Running Tasks:
http://wiki.wxpython.org/LongRunningTasks
A>
Robin Dunn
> Hi all,
>
> I'm in Boa Constructor.
>
> I press the help button and I get C++ code.... I don't understand C++ code.
>
> How can I find out how to use the Splitterwindow?
http://wiki.wxpython.org/C%2B%2BGuideForwxPythoneers
--
Robin Dunn
Software Craftsman
http://wxPython.org
David Lyon
<werner...@free.fr> wrote:
>>> How can I find out how to use the Splitterwindow?
>>
>>
>> http://wiki.wxpython.org/C%2B%2BGuideForwxPythoneers
> Boa includes both the C++ doc and the new wxPython doc.
>
> If you do ctrl-h and then enter splitterwindow and press ok you will see
> both. The entries starting with "wxSplitter" are the C++ doc and the
> ones on the top e.g. "SplitterWindow" are from the new doc.
This is all less than helpful...
The presumption placed upon the read is that they already know wxwidgets,
already know what all the controls do, that they know how to program it all
in C++... and they just want to do the same thing in wxpython.
Quoting wrappers in C++ is like being read back text from a Latin lawbook..
What an application developer wants to know is what are the components..
What is the relationship between them.... and how are they used together to
make an application window that sizes nicely.
None of these questions are covered in the documentation...
Here's an analogy of how this documentation was written..
Somebody makes a road. Somebody else wants to use it to drive a car down to
the shops....
The road maker writes down all the fun things like the chemical composition
of the bitumen and chucks in for "free" the timecards of all of the various
steamroller driver as a reference...
what more could any driver need....? right?
It's the same with this documentation. No python programmer can use the
wrappers. They make no sense. And are transient and irrelevant.
But... just like a chemical composition of a road... it's being held in the
highest esteem... for all pedestrians and motorists alike....
I'm sorry - I'm just trying to explain very clearly what the problem with
the existing documentation is.
But if nobody cares... it doesn't matter...
David
Werner F. Bruhin
David Lyon wrote:
> On Tue, 26 May 2009 09:15:00 +0200, "Werner F. Bruhin"
> <werner...@free.fr> wrote:
>
>
>>>> How can I find out how to use the Splitterwindow?
>>>>
>>> http://wiki.wxpython.org/C%2B%2BGuideForwxPythoneers
>>>
>> Boa includes both the C++ doc and the new wxPython doc.
>>
>> If you do ctrl-h and then enter splitterwindow and press ok you will see
>> both. The entries starting with "wxSplitter" are the C++ doc and the
>> ones on the top e.g. "SplitterWindow" are from the new doc.
>>
>
> This is all less than helpful...
>
> The presumption placed upon the read is that they already know wxwidgets,
> already know what all the controls do, that they know how to program it all
> in C++... and they just want to do the same thing in wxpython.
>
Both these docs are reference doc, they are not how to docs.
In Boa there is a little tutorial to get going with Boa/wxPython - if
you have some suggestions on how that could be enhanced to make it
easier, you can either write it and I will incorporate it or you can
just make some suggestions and I will add it to my todo list.
There are also some ShowMeDo videos for wxPython.
http://showmedo.com/videos/series?name=PythonWxPythonBeginnersSeries -
5 videos
http://showmedo.com/videotutorials/series?name=wKQrywla5 - 9 videos on Boa
- Then one of the best tools to get going is the wxPython demo (a
separate download with the docs).
- Then there is the wiki
http://wiki.wxpython.org/How%20to%20Learn%20wxPython\
http://wiki.wxpython.org/ObstacleCourse
and many more
> Quoting wrappers in C++ is like being read back text from a Latin lawbook..
>
Frankly I was and I am still getting very confused when I look at the
C++ doc, in the rare cases when I can not find an answer in the other docs.
But there are good reasons why it is that way and Robin and others have
only so much time in a day, i.e. 24 also I wonder sometimes if Robin
figured out how to get 48 out of day.
Here some help/information on this:
http://wiki.wxpython.org/C%2B%2BGuideForwxPythoneers
http://wiki.wxpython.org/C%2B%2B%20%26%20Python%20Sandwich
http://wiki.wxpython.org/C%2B%2BExtensions
And last but not least this is the wxpython-users list, a lot of
extremely nice and helpful bunch of people hang out here and they are
always very helpful when one asks nicely.
Werner
Werner F. Bruhin
Robin Dunn wrote:
> David Lyon wrote:
>> Hi all,
>>
>> I'm in Boa Constructor.
>> I press the help button and I get C++ code.... I don't understand C++
>> code.
>>
>> How can I find out how to use the Splitterwindow?
>
>
> http://wiki.wxpython.org/C%2B%2BGuideForwxPythoneers
Boa includes both the C++ doc and the new wxPython doc.
If you do ctrl-h and then enter splitterwindow and press ok you will see
both. The entries starting with "wxSplitter" are the C++ doc and the
ones on the top e.g. "SplitterWindow" are from the new doc.
Werner
David Lyon
> Both these docs are reference doc, they are not how to docs.
Not really. They don't provide any "reference" points...
There's nothing that a python programmer needs in the
current documentation...
Sadly... it doesn't work very well as reference material.
> In Boa there is a little tutorial to get going with Boa/wxPython - if
> you have some suggestions on how that could be enhanced to make it
> easier, you can either write it and I will incorporate it or you can
> just make some suggestions and I will add it to my todo list.
The wxpython documentation needs revising. It just needs a fresh
rework from an application developers perspective.
That means... what wxpython has.... what it gives you...
and some proper pythonic examples and references...
> - Then one of the best tools to get going is the wxPython demo (a
> separate download with the docs).
Yes - but the example python code needs to be where the C++ code
currently sits. Right where you need it. Not in some seperate
system that needs a seperate download. That's not how good
documentation works.
> But there are good reasons why it is that way and Robin and others have
> only so much time in a day, i.e. 24 also I wonder sometimes if Robin
> figured out how to get 48 out of day.
Well I understand that completely...
But likewise, the burden of all the documentation shouldn't lie on
Robin alone.
> Here some help/information on this:
> http://wiki.wxpython.org/C%2B%2BGuideForwxPythoneers
> http://wiki.wxpython.org/C%2B%2B%20%26%20Python%20Sandwich
> http://wiki.wxpython.org/C%2B%2BExtensions
Man... (sigh)
That's a lot of documentation to have to read to find out an
answer to how to set up splitter components on a wxpython app...
I already found the spot in the reference material where it
was supposed to be but their was nothing written.
If you're somehow suggesting that I read through all the
documentation and somehow colate it into something useful
I probably would be a bit more positive....
To mind.. the existing documentation structure is pretty good. It
just needs revising. Adding better descriptions of what the classes
do... Listing the key properties and methods.. and providing
an in-situ example that a developer can cut and paste directly.
That's basically what I am suggesting needs doing.
> And last but not least this is the wxpython-users list, a lot of
> extremely nice and helpful bunch of people hang out here and they are
> always very helpful when one asks nicely.
Yes - I don't doubt that.
But application developers too have only so many hours in the day.
I don't blame any application developer for being annoyed when they
have to work 4 hours extra hunting through useless documentation
and google till 3am to answer a question on how to do something that
should have been a two minute task....
You may say you are helpful, but I never got an answer on what
I need to do to put the splitter components together into something
working. Like I said... I gave up... moved onto something else...
:-)
David
(ps: I have a client who uses dBase IV. I dream for documentation
that good. Would anybody be interested to see scans of their
documentation? It takes only 2 mins to get an answer on literally
anything from their reference manual. And that is a paper book! )
Domenico Nappo
In addition to what Anthony suggested, I recommend checking out the demo. There is a couple of widgets in there that you could use for the progress bar and some examples of threading as well.
Really useful!! I'll let you know :)
PbuY
--
DN
Steven Sproat
> [snip snip snip]
>
> What an application developer wants to know is what are the components..
> What is the relationship between them.... and how are they used together to
> make an application window that sizes nicely.
>
> None of these questions are covered in the documentation...
>
>
>
Hi David,
Have you looked at the wxpython demo? It shows you how to use the
splitterctrl there
(unrelated to the topic...)
Also is it me or is Google Groups being weird, for example this very
thread, here
http://groups.google.com/group/wxPython-users/browse_thread/thread/e19fd7788995165e
somehow inserts Domenico's post halfway through the thread, when in fact
it is a new message.
Michael Moriarity
>> And last but not least this is the wxpython-users list, a lot of
>> extremely nice and helpful bunch of people hang out here and they are
>> always very helpful when one asks nicely.
>
> Yes - I don't doubt that.
>
> But application developers too have only so many hours in the day.
>
> I don't blame any application developer for being annoyed when they
> have to work 4 hours extra hunting through useless documentation
> and google till 3am to answer a question on how to do something that
> should have been a two minute task....
>
> You may say you are helpful, but I never got an answer on what
> I need to do to put the splitter components together into something
> working. Like I said... I gave up... moved onto something else...
>
> :-)
>
> David
>
> (ps: I have a client who uses dBase IV. I dream for documentation
> that good. Would anybody be interested to see scans of their
> documentation? It takes only 2 mins to get an answer on literally
> anything from their reference manual. And that is a paper book! )
While all of your complaints seem to be valid in some abstract sense,
many of us have simply made do with the documentation there is,
because we find the usefulness of the toolkit so great that we are
happy to make the trade off. If you do not feel this way, you should
simply use another toolkit which better fits your needs, or write the
documentation you desire. That's how it works in the free software
world.
--
Best Regards,
Michael Moriarity
Robin Dunn
Robin Dunn
> (unrelated to the topic...)
> Also is it me or is Google Groups being weird, for example this very
> thread, here
> http://groups.google.com/group/wxPython-users/browse_thread/thread/e19fd7788995165e
> somehow inserts Domenico's post halfway through the thread, when in fact
> it is a new message.
The script I wrote to transfer the archives does so by emailing each
message to the group's archive address. It looks like if the messages
arrive out of order then that is how the get put into the discussions,
instead of using the date or the In-Reply-To header to define the order.
This is why Mike's reply to Dominic is shown before Dominic's message.
There is another issue in the thread you linked. Notice the boxes with
"Discussion subject changed to..." in them. This happens when somebody
replies to an existing message and changes the subject instead of
creating a new message with the new subject. This is why Dominic's
message about the observer pattern shows up in the discussion about
splitter docs.
Robin Dunn
> You may say you are helpful, but I never got an answer on what
> I need to do to put the splitter components together into something
> working. Like I said... I gave up... moved onto something else...
>
Well, maybe I missed it but I never saw an actual question about
splitter windows. Just a rant.
BTW, documentation is something always on my mind and I've been putting
some thought into how to automate most of it so it doesn't require
having 48 hour days to keep it maintained. The "new" wxPython docs was
one attempt that didn't work out so well. I'm gearing up for the next
attempt in the not too distant future.
Robin Dunn
> Hi David,
>
> On May 26, 2009, at 6:03 PM, David Lyon wrote:
>
>> On Tue, 26 May 2009 20:52:45 -0400, C M <cmpy...@gmail.com> wrote:
>>
>>> Are you referring to the regime-mandated micromanagerial
>>> prevention of his creation the docs themselves, GUI2Exe, or
>>> the about 36 widgets (one of which is a pure Python version of
>>> the long sought AUI) he has contributed?
>>
>> I'm saying development of the documentation is moving at
>> 0.5 km/year....
>>
>> Instead of one person doing all the work, somebody with an
>> interest in improving the documentation needs to be given
>> the responsibility to implement improvement.
>>
>> That is - allowed to make decisions...
>
> He actually has commit access to parts of the wxPython tree.
>
> Regarding why his contribution wasn't accepted, it's because IIRC from
> our previous discussions, he basically manually copied and pasted all
> the wxWidgets docs into Python docstrings. Robin and I have been (yes,
> slowly...) working towards an automated process for copying over
> wxWidgets documentation updates into Python, but conditionally allowing
> for overriding those docs with Python specific docs. If we had applied
> Andrea's changes, it would have basically meant that *all* future doc
> updates would need to be manually done as well, as the automated system
> we had planned would no longer be useful. That's a big downside.
In other words, it would be a complete fork of the documentation, which
is something like 2300 pages of text that would need to be kept in sync
with changes in the C++ docs. So instead of reducing work it would
dramatically increase the maintenance load and so spreading the work
from a-few-of-us to a-few-of-us +1 would actually be a big step
backwards. This has been attempted many times in the past and in those
cases every person who has taken that burden on themselves eventually
got burned out and totally left the project. I certainly don't want
that to happen to Andrea because he has great value to me and to the
project in other areas and I would hate to lose his ongoing work in
those areas. That is why I discouraged him from continuing on that path
and why I am still committed to finding the right 95% automated
solution. (So yes, I am delegating and making management level
decisions for this project.)
I like to think of Andrea's work on the docs as a very good and usable
proof of concept of using the Sphinx tool for the wxPython docs. My
intent is to still use Sphinx for generating the final output, but also
to generate much of the input from the C++ document tree with specific
snippets overridden as necessary to turn them into Python-specific bits
of text. If it's done right then anybody will be able to submit
documentation patches and once someone has proven themselves they can be
given SVN access to do the work directly, and it may only take a few
minutes per week to keep everything in shape. There are a few other
BDFL level decisions that need to be made before we get to that point,
but we'll get there. There is a mostly clear path from here to there in
my mind, and once I get some of those decisions made and the groundwork
laid then others will be able to jump in and help out to a greater extent.
Andrea Gavana
Robin Dunn wrote:
<snip>
<snap>
Kevin Ollivier wrote:
<snip>
<snap>
Two posts, which say basically the same thing, but what a difference in style...
My original post, here:
http://lists.wxwidgets.org/pipermail/wxpython-dev/2008-November/004048.html
makes no mention of replacing the official wxPython docs with mine, it
merely asks if there is any interest in the Sphinx-based documentation
I generated. As Robin correctly said, it was a proof of concept.
Moreover, it's not that I am no more interested in the automatic
generation of the docs (au contraire), I am just waiting to see which
will be the final decision on *how* the docs will be dealt with in
wxPython. After that, I am more than willing to help to generate
eye-catching and complete docs.
My line of reasoning was:
1) Is there any way to transform/adapt the C++ docs and then put them
as Python docstrings?
2) If the answer to (1) is "yes", use the Sphinx-autodoc feature to
generate the documentation automagically with almost no need of human
intervention.
Looking at the power of Sphinx (see the matplotlib, numpy, Python 2.6
docs and many more), if the aforementioned line of thought can be
implemented we could put CHM, doxygen-based, epydoc-based and
whatever-based documentation in the recycle bin.
I'll wait until our BDFL ( :-D ) will come up with a nice solution for
the wxPython docs, everything else is just academic discussion.
<rant>
Not to mention the subtle but evident irony of some posts.
<rant/>
Andrea.
"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/
http://thedoomedcity.blogspot.com/
David Lyon
> 2) If the answer to (1) is "yes", use the Sphinx-autodoc feature to
> generate the documentation automagically with almost no need of human
I'm going to be looking into understanding how the existing doxygen
system runs over the coming week. Legacy code... I love it...
What I'm trying to find is where it outputs all it's xml files for every class.
That will hopefully give me a definitive list of (active) classes..
I'll write a merging tool to check for local class documentation and
if a class documentation file isn't found by name, then use the other
doxygen xml file.
I think I have everything I need till them.
This isn't the highest priority I have at the moment, but I should be
able to come up with something by next week.
After the proof of concept that you showed, I get the impression that
there is a general consensus that a move to sphinx will bring some
fresh change into the project, providing certain conditions are met.
Thanks for showing us the way forward.....
David
David Lyon
David Lyon
Are you willing to share your source for this - so that it can be worked on ?
http://xoomer.virgilio.it/infinity77/wxPython/index.html
I would like to improve it...
Regards
David
David Lyon
wrote:
> If you do not feel this way, you should
> simply use another toolkit which better fits your needs, or write the
> documentation you desire. That's how it works in the free software
> world.
Last time I offered to help with the documentation I was told
there was no spare capacity for me to do that.
So rather than do anything constructive to sort out the problem...
(... which might actually be a quicker option... )
I'll just continue to provide feedback on what whatever issue I
come across and report it back every day - haha
Like I said before.. I'm just trying to do a python package manager
using wxwidgets. I'm from a Delphi/VB background. If I stumble upon
any problem... I'll check the documentation.... and if I find
nothing then I'll ask on the list....
That's what I've been told on numerous occasions to do.
So really, you just have to put up with people that are
following the instructions given out to them....
And since I'm not allowed to contribute to the documentation
(like I would in a normal open-source project) these
questions/suggestions of mine are going to be going on
for a very long time.... because I'm many years away
from retirement just yet...
( ..and so the world moves ever so slowly forward.. )
David
Robin Dunn
Robin Dunn
> (unrelated to the topic...)
> Also is it me or is Google Groups being weird, for example this very
> thread, here
> http://groups.google.com/group/wxPython-users/browse_thread/thread/e19fd7788995165e
> somehow inserts Domenico's post halfway through the thread, when in fact
> it is a new message.
The script I wrote to transfer the archives does so by emailing each
message to the group's archive address. It looks like if the messages
arrive out of order then that is how the get put into the discussions,
instead of using the date or the In-Reply-To header to define the order.
This is why Mike's reply to Dominic is shown before Dominic's message.
There is another issue in the thread you linked. Notice the boxes with
"Discussion subject changed to..." in them. This happens when somebody
replies to an existing message and changes the subject instead of
creating a new message with the new subject. This is why Dominic's
message about the observer pattern shows up in the discussion about
splitter docs.
--
Robin Dunn
> You may say you are helpful, but I never got an answer on what
> I need to do to put the splitter components together into something
> working. Like I said... I gave up... moved onto something else...
>
Well, maybe I missed it but I never saw an actual question about
splitter windows. Just a rant.
BTW, documentation is something always on my mind and I've been putting
some thought into how to automate most of it so it doesn't require
having 48 hour days to keep it maintained. The "new" wxPython docs was
one attempt that didn't work out so well. I'm gearing up for the next
attempt in the not too distant future.
--
David Lyon
> BTW, documentation is something always on my mind and I've been putting
> some thought into how to automate most of it so it doesn't require
> having 48 hour days to keep it maintained.
I really don't mind pitching in to help out.
Whilst it is a considerable task, it's not an enormous one.
I propose something like this:
- re-categorise all the controls similar to the order
shown on the boa constructor (or some other ide) tool.
ie (panels, buttons, lists, dialogs etc)
- We write/find an abstract for every wxwidget.
(Not as bad as it sounds - might take 3 weeks)
- We find an example for every widget.
(might take 2 months)
- We identify and document the properties/methods/events
for every widget.
(might take a little while...)
I strongly suggest moving the documentation into Sphinx
format.
Whilst I'm only learning sphinx, I can see it's advantages.
One writes in plain text... then compiles it to html..
The results that I have seen look pretty good.
It is a native python tool..
I do have some spare time... that I can allocate...
Regards
David
Werner F. Bruhin
Robin Dunn wrote:
...
>>
>> http://wiki.wxpython.org/How%20to%20Learn%20wxPython\
>> http://wiki.wxpython.org/ObstacleCourse
>> and many more
>>
>
> Don't forget the wxPIA: http://wiki.wxpython.org/wxPythonInAction
It was included in the many more :-) .
Werner
Mike Driscoll
> Hi all,
>
> I'm in Boa Constructor.
>
> I press the help button and I get C++ code.... I don't understand C++ code.
>
>
> constructor...
>
> How do I use these things? I have a very simple app...
>
I don't use Boa, but I went ahead and created a very simple example of
how to create a splitter. The demo gives the same info, but it's
probably more in depth. I see you decided to go do something else, but
hopefully the attached file will help you out in the future...
I ran this under Windows XP, wxPython 2.8.9.2, Python 2.5
- Mike
Mike Driscoll
Oh yeah...I forgot to plug Andrea's docs, which I use as an alternative
to the official docs:
- Mike
David Lyon
> Oh yeah...I forgot to plug Andrea's docs, which I use as an alternative
> to the official docs:
>
>
http://xoomer.virgilio.it/infinity77/wxPython/Widgets/wx.SplitterWindow.html?highlight=splitterwindow
Look.. the layout of this documentation is very good.
The only thing lacking in my mind is an in-situ example...
What I think is needed is to pull all the existing documentation
somehow together into a format very much like this. Perphaps
placing author names on the pages where that is appropriate.
David
David Lyon
http://xoomer.virgilio.it/infinity77/wxPython/index.html
This site that Mike showed is quite close to what an
application developer needs to have in official wxwidgets
documentation.
What is missing from the above:
- requires re-categorization of the widgets into their
logical developer groups (panels,button,dialogs,lists etc)
- an example for every class
- completion for *all* classes
And look... it is done with sphinx....
So very very nice.....
David Lyon
wrote:
>>
>> http://xoomer.virgilio.it/infinity77/wxPython/index.html
>> So very very nice.....
>
> Thank you.
>
> I did it a while ago when I felt that the wxPython docs needed some
> refreshing look, but after that nothing has changed. We'll wait and
> see the new ideas Robin will propose for the documentation.
Yes... well the fact that nothing is improving and talents and efforts
of good people are going to waste is very disappointing.
In the business world.. this would be called failure to delegate...
or micro-management...
What we need is that one person.... (not the developer) to be
delegated the job of documentation. And left to coordinate
the role which may require using the skills of multiple people.
Obviously - you wasted your time making suggestions... I am
wasting my time making suggestions....
The original developer won't lose control by delegating..
Rather.. becomes more powerful because there are more people
giving support.
Yes - I'm complaining very loudly that Andrea's efforts and
talents and those of others are being wasted in a micromanaged
regime....
Andrea Gavana
>
> http://xoomer.virgilio.it/infinity77/wxPython/index.html
>
> This site that Mike showed is quite close to what an
> application developer needs to have in official wxwidgets
> documentation.
*wxPython*. wxWidgets docs are far from being as nice as the Sphinx-based ones.
> What is missing from the above:
>
> - requires re-categorization of the widgets into their
> logical developer groups (panels,button,dialogs,lists etc)
>
> - an example for every class
>
> - completion for *all* classes
>
> And look... it is done with sphinx....
>
> So very very nice.....
Thank you.
I did it a while ago when I felt that the wxPython docs needed some
refreshing look, but after that nothing has changed. We'll wait and
see the new ideas Robin will propose for the documentation.
Andrea.
Christopher Barker
> What we need is that one person.... (not the developer) to be
> delegated the job of documentation.
This is an open source project -- you don't get delgated -- you
volunteer. Robin is the BDFL of wxPython, but that's because he does
almost all the work.
Feel free to step up and do what you think should be done -- it will be
appreciated!
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
David Lyon
> BTW, documentation is something always on my mind and I've been putting
> some thought into how to automate most of it so it doesn't require
> having 48 hour days to keep it maintained.
One easy way to address the problem is to delegate the role
to somebody else...
> The "new" wxPython docs was one attempt that didn't work out so well.
> I'm gearing up for the next
> attempt in the not too distant future.
I don't understand why you take it upon yourself to be responsible
for all the documentation.
Your efforts are best placed just working on the stuff that you
are good at... and let others do the same
Delegate the "Documentation" to somebody else to coordinate.
At the end of the day you still have the final say...
The talent surrounds you.... but you want to do everything
yourself....
Give your self a promotion.....
move up the food chain....
Take charge ...
stop being the janitor...
David
C M
Are you referring to the regime-mandated micromanagerial
prevention of his creation the docs themselves, GUI2Exe, or
the about 36 widgets (one of which is a pure Python version of
the long sought AUI) he has contributed?
Or are you talking about some other Andrea Gavana?
Che
David Lyon
> Are you referring to the regime-mandated micromanagerial
> prevention of his creation the docs themselves, GUI2Exe, or
> the about 36 widgets (one of which is a pure Python version of
> the long sought AUI) he has contributed?
I'm saying development of the documentation is moving at
0.5 km/year....
Instead of one person doing all the work, somebody with an
interest in improving the documentation needs to be given
the responsibility to implement improvement.
That is - allowed to make decisions...
That would double the size of the team to two people....
is that not unreasonable?
grunculus
On Tue, May 26, 2009 at 6:29 PM, David Lyon <david...@preisshare.net> wrote:
> On Tue, 26 May 2009 12:34:59 -0500, Mike Driscoll <mi...@pythonlibrary.org>
>> Oh yeah...I forgot to plug Andrea's docs, which I use as an alternative
>> to the official docs:
>>
>>
> http://xoomer.virgilio.it/infinity77/wxPython/Widgets/wx.SplitterWindow.html?highlight=splitterwindow
>
> Look.. the layout of this documentation is very good.
>
> The only thing lacking in my mind is an in-situ example...
If you haven't seen it already, you might want to review some of the
previous threads on wxPython documentation, e.g.
> What I think is needed is to pull all the existing documentation
> somehow together into a format very much like this. Perphaps
> placing author names on the pages where that is appropriate.
I think you're underestimating the task.
Comparing the wxPython documentation to Delphi's or DBase is comparing
apples and elephants. Borland/Interbase/whatever they're called now
control the language and the entire tool chain. It is easy for them
to have everything in one place.
As Robin points out above, wxPython (python) is a wrapper around
wxWidgets (C++). He's trying to automate as much of it as possible,
but it's still a labor-intensive task, especially since Python and
wxWidgets are in active development. Moving examples into the
documentation in a way that is compatible with the automatic document
generation of wxWidgets and Robin's tools is yet another huge task.
I wholeheartedly agree that it would be nice, in an abstract sense, to
be able to hit F1 and have all of the class definitions, etc., along
with a code example pop-up all in one place. It would also be great
if many of the examples out there were updated to match the latest
coding style. I think you're tilting at windmills, though.
I'm also a newbie at wxPython. I have Robin's book and have tried to
follow the examples on the Wiki, Zetcode, and elsewhere. I personally
find that the the vast majority of examples on the Wiki are far too
simple to extend from a low knowledge state to try to use in a real
project, yet other things like Chandler, or Phatch, or SPE are far too
complex for me to grok yet. Even many of Andrea's widget examples are
pretty complex for me.
As a more concrete for instance: I would love to be able to take Unit
Converter - http://sourceforge.net/projects/unit-converter/ - and
easily put it on a Notebook page. I would then like to convert it to
use Sizers, as a learning exercise. Similarly, I would like to
understand how to use code that is divided up into source files in
sub-directories in several projects. For example as in version 0.6 of
BBCalc - http://www.mirrorservice.org/sites/download.sourceforge.net/pub/sourceforge/b/bb/bbcalc/
- (note that later versions are rewritten to use pyGTK). I know how
spaghetti-code develops and I would like to start off in wxPython with
good habits. I'm sure most of my questions will be answered in time,
as I devote more time to working with the language and tools.
Ultimately, open source projects thrive or fail based on the work put
into them. If you want to add examples to wxPython's documentation,
feel free. I'm sure you'll get lots of encouragement. But don't be
surprised if others can't use what you come up with because they have
to use automated tools to keep things in sync with wxWidgets.
My $0.02.
Cheers,
Scott.
> David
David Lyon
> I think you're underestimating the task.
No - I don't think I am.
> Comparing the wxPython documentation to Delphi's or DBase is comparing
> apples and elephants. Borland/Interbase/whatever they're called now
> control the language and the entire tool chain. It is easy for them
> to have everything in one place.
Comparing wxwidgets and Delphi is comparing apples with apples.
They both set out as GUI development tools...
I grant you that Delphi was an inhouse development and controlled
the entire food chain as you say.
Here, we don't control the entire food chain.. we get stuff from
upstream.. in the form of wx...
> As Robin points out above, wxPython (python) is a wrapper around
> wxWidgets (C++). He's trying to automate as much of it as possible.
Well Developers don't want automatically generated documentation.
It's useless.
If we replaced the C++ code in the documentation with hex dumps
we could automate it even more....
> but it's still a labor-intensive task, especially since Python and
> wxWidgets are in active development.
Yes I grant that...
But developers can only take so much information...
We don't have documentation on the simple stuff like splitters...
> Moving examples into the
> documentation in a way that is compatible with the automatic document
> generation of wxWidgets and Robin's tools is yet another huge task.
So what. Stop turning away volunteers.
> I wholeheartedly agree that it would be nice, in an abstract sense, to
> be able to hit F1 and have all of the class definitions, etc., along
> with a code example pop-up all in one place. It would also be great
> if many of the examples out there were updated to match the latest
> coding style.
Sure. It's what most other projects can accomplish.
> Ultimately, open source projects thrive or fail based on the work put
> into them. If you want to add examples to wxPython's documentation,
> feel free.
I'm not free to do that.
> I'm sure you'll get lots of encouragement. But don't be
> surprised if others can't use what you come up with because they have
> to use automated tools to keep things in sync with wxWidgets.
I know... they love their hex dumps....
sorry C++ dumps....
As an application developer.. I could have read what Andrea wrote..
It was on the way to being good documentation.
David
David Lyon
> So, what did you already propose you would do,
Promote Robin from "Software Craftsman" to "Master Software Craftsman"..
> and what was the outcome of that?
We're waiting on a decision...
David
C M
I am giving you a little guff because of the hyperbole. :)
So, what did you already propose you would do, and what
was the outcome of that?
Che
Kevin Ollivier
On May 26, 2009, at 6:03 PM, David Lyon wrote:
> On Tue, 26 May 2009 20:52:45 -0400, C M <cmpy...@gmail.com> wrote:
>
>> Are you referring to the regime-mandated micromanagerial
>> prevention of his creation the docs themselves, GUI2Exe, or
>> the about 36 widgets (one of which is a pure Python version of
>> the long sought AUI) he has contributed?
>
> I'm saying development of the documentation is moving at
> 0.5 km/year....
>
> Instead of one person doing all the work, somebody with an
> interest in improving the documentation needs to be given
> the responsibility to implement improvement.
>
> That is - allowed to make decisions...
He actually has commit access to parts of the wxPython tree.
Regarding why his contribution wasn't accepted, it's because IIRC from
our previous discussions, he basically manually copied and pasted all
the wxWidgets docs into Python docstrings. Robin and I have been (yes,
slowly...) working towards an automated process for copying over
wxWidgets documentation updates into Python, but conditionally
allowing for overriding those docs with Python specific docs. If we
had applied Andrea's changes, it would have basically meant that *all*
future doc updates would need to be manually done as well, as the
automated system we had planned would no longer be useful. That's a
big downside.
Had Andrea bothered to consult wxPython-dev or ask Robin directly
before he went and did all this work, he'd have known all about this
issue before putting his time and effort into it. However, I think
even Robin only learned about Andrea's work at the same time everyone
else did, which was when he posted his finished product to wxPython-
users. If Andrea had really been concerned about getting his work
accepted and part of the official project to help all current and
future wxPythoneers, all it would have taken would have been for him
to contact wxPython-dev or wxPython-users (or just Robin) beforehand,
see what others were working on, and collaborate with them so we could
all work together to get to the finish line sooner. I don't really see
why he didn't do so, as it seems a fairly obvious and logical thing to
do IMHO.
As for the automated doc generation, Andrea hasn't so far shown an
interest in making that happen (well, publicly, who knows if he's
actually working on something...), and Robin and I are swamped with
other efforts, though as a start I have written scripts to parse the
Doxygen docs into Python objects. (see http://trac.wxwidgets.org/browser/wxWidgets/trunk/docs/doxygen/scripts)
, which mostly leaves parsing some Doxygen tags into docstrings, and I
don't think it'll be a huge task.
In fact, I want to actually allow the SWIG bindings to be mostly auto-
generated too, so that we can reduce the maintenance burden on this
project as much as possible to free people up to do funner and more
innovative things, which I think would actually have a huge positive
impact on the project. But, like Robin, I have a lot of other
responsibilities on my plate, mostly bread and butter issues that have
to come first. I want the prettier and more complete docs as much as
anyone else, but to use your corporate analogy, there's a big
difference between hacking together a nice demo that impresses the
boss, and developing a solution that is sustainable, robust and low
maintenance. Manually keeping track of, and copying and pasting, every
change from a documentation tree that changes almost daily is not what
I would call a sustainable solution. I think the wxPython project
would enthusiastically welcome any help in getting us out of that
mess, but I don't really support any change that gets us deeper into it.
Regards,
Kevin
> is that not unreasonable?
> _______________________________________________
> wxpython-users mailing list
> wxpytho...@lists.wxwidgets.org
> http://lists.wxwidgets.org/mailman/listinfo/wxpython-users
Robin Dunn
> Hi David,
>
> On May 26, 2009, at 6:03 PM, David Lyon wrote:
>
>> On Tue, 26 May 2009 20:52:45 -0400, C M <cmpy...@gmail.com> wrote:
>>
>>> Are you referring to the regime-mandated micromanagerial
>>> prevention of his creation the docs themselves, GUI2Exe, or
>>> the about 36 widgets (one of which is a pure Python version of
>>> the long sought AUI) he has contributed?
>>
>> I'm saying development of the documentation is moving at
>> 0.5 km/year....
>>
>> Instead of one person doing all the work, somebody with an
>> interest in improving the documentation needs to be given
>> the responsibility to implement improvement.
>>
>> That is - allowed to make decisions...
>
> He actually has commit access to parts of the wxPython tree.
>
> Regarding why his contribution wasn't accepted, it's because IIRC from
> our previous discussions, he basically manually copied and pasted all
> the wxWidgets docs into Python docstrings. Robin and I have been (yes,
> slowly...) working towards an automated process for copying over
> wxWidgets documentation updates into Python, but conditionally allowing
> for overriding those docs with Python specific docs. If we had applied
> Andrea's changes, it would have basically meant that *all* future doc
> updates would need to be manually done as well, as the automated system
> we had planned would no longer be useful. That's a big downside.
In other words, it would be a complete fork of the documentation, which
is something like 2300 pages of text that would need to be kept in sync
with changes in the C++ docs. So instead of reducing work it would
dramatically increase the maintenance load and so spreading the work
from a-few-of-us to a-few-of-us +1 would actually be a big step
backwards. This has been attempted many times in the past and in those
cases every person who has taken that burden on themselves eventually
got burned out and totally left the project. I certainly don't want
that to happen to Andrea because he has great value to me and to the
project in other areas and I would hate to lose his ongoing work in
those areas. That is why I discouraged him from continuing on that path
and why I am still committed to finding the right 95% automated
solution. (So yes, I am delegating and making management level
decisions for this project.)
I like to think of Andrea's work on the docs as a very good and usable
proof of concept of using the Sphinx tool for the wxPython docs. My
intent is to still use Sphinx for generating the final output, but also
to generate much of the input from the C++ document tree with specific
snippets overridden as necessary to turn them into Python-specific bits
of text. If it's done right then anybody will be able to submit
documentation patches and once someone has proven themselves they can be
given SVN access to do the work directly, and it may only take a few
minutes per week to keep everything in shape. There are a few other
BDFL level decisions that need to be made before we get to that point,
but we'll get there. There is a mostly clear path from here to there in
my mind, and once I get some of those decisions made and the groundwork
laid then others will be able to jump in and help out to a greater extent.
David Lyon
On Tue, 26 May 2009 19:58:26 -0700, Kevin Ollivier
> Regarding why his contribution wasn't accepted, it's because IIRC from
> our previous discussions, he basically manually copied and pasted all
> the wxWidgets docs into Python docstrings.
I see...
> Robin and I have been (yes,
> slowly...) working towards an automated process for copying over
> wxWidgets documentation updates into Python, but conditionally
> allowing for overriding those docs with Python specific docs.
Ok - makes sense.
> If we
> had applied Andrea's changes, it would have basically meant that *all*
> future doc updates would need to be manually done as well, as the
> automated system we had planned would no longer be useful. That's a
> big downside.
Perphaps you don't see the value in Andrea's (handcrafted) work...
Everything he has done can be extracted to metadata..
(sphinx generates from metadata)
It can all merged with an automated documentation generation process..
> Had Andrea bothered to consult wxPython-dev or ask Robin directly
> before he went and did all this work, he'd have known all about this
> issue before putting his time and effort into it.
But he correctly identified that the problem with the documentation
is the lack of any human touch..
> However, I think
> even Robin only learned about Andrea's work at the same time everyone
> else did, which was when he posted his finished product to wxPython-
> users. If Andrea had really been concerned about getting his work
> accepted and part of the official project to help all current and
> future wxPythoneers, all it would have taken would have been for him
> to contact wxPython-dev or wxPython-users (or just Robin) beforehand,
> see what others were working on, and collaborate with them so we could
> all work together to get to the finish line sooner. I don't really see
> why he didn't do so, as it seems a fairly obvious and logical thing to
> do IMHO.
History shows that what he has done has been rejected...
If he had asked in the first place - the outcome would have been that
his offer of help would have been rejected - I'm very sure.
> In fact, I want to actually allow the SWIG bindings to be mostly auto-
> generated too, so that we can reduce the maintenance burden on this
> project as much as possible to free people up to do funner and more
> innovative things, which I think would actually have a huge positive
> impact on the project. But, like Robin, I have a lot of other
> responsibilities on my plate, mostly bread and butter issues that have
> to come first. I want the prettier and more complete docs as much as
> anyone else, but to use your corporate analogy, there's a big
> difference between hacking together a nice demo that impresses the
> boss, and developing a solution that is sustainable, robust and low
> maintenance. Manually keeping track of, and copying and pasting, every
> change from a documentation tree that changes almost daily is not what
> I would call a sustainable solution. I think the wxPython project
> would enthusiastically welcome any help in getting us out of that
> mess, but I don't really support any change that gets us deeper into it.
Ok. So here it is in a nutshell...
You and Robin want automatically generated documentation...
Developers want the documentation in a format that they
find useable in a day-to-day sense.
The problem, as you see it, is that there is a ton of input data
coming in each day from the c++ side of wx. And you want
that included....
It's a much more common problem than you may think...
Most people would use xml/rest files (say one per class)..
We'll have two sets of data... (local) + (imported)....
local is what is handwritten.. imported is what
comes from wx
Another file holds a master list of classes (in an xml file)...
Merge the three lists... pull from imported where
it isn't in local....
Use restructed text.. as Andrea did..
Do xml or cheetah transformations..
Having an automated system isn't a problem...
What I would need to combine everybodies efforts is a
branch on the svn tree... Same as everyone I have other
bread and butter issues too..
I am not promising anything overnight. But if we get
the right structure in place.. I am not sure the task is so
hard.
David
David Lyon
> In other words, it would be a complete fork of the documentation
Yes.
> which is something like 2300 pages of text that would need to be kept in
sync
> with changes in the C++ docs.
Not necessarily.
It's one xml/rest file per class for every class that we choose to
document.
How many resulting pages that get generated as a result is irrelevant.
You're thinking of 2300+ pages coming into the system...
A developer is thinking about one page... breaking out to the 2300+ pages
that they need....
> I like to think of Andrea's work on the docs as a very good and usable
> proof of concept of using the Sphinx tool for the wxPython docs.
Exactly....
> .. use Sphinx for generating the final output, but also
> to generate much of the input from the C++ document tree with specific
> snippets overridden as necessary to turn them into Python-specific bits
> of text.
So true...
> and it may only take a few
> minutes per week to keep everything in shape.
That's what I'm thinking too...
Take care
David
Kevin Ollivier
On May 26, 2009, at 8:50 PM, David Lyon wrote:
>
> On Tue, 26 May 2009 19:58:26 -0700, Kevin Ollivier
>
>> Regarding why his contribution wasn't accepted, it's because IIRC
>> from
>> our previous discussions, he basically manually copied and pasted all
>> the wxWidgets docs into Python docstrings.
>
> I see...
>
>> Robin and I have been (yes,
>> slowly...) working towards an automated process for copying over
>> wxWidgets documentation updates into Python, but conditionally
>> allowing for overriding those docs with Python specific docs.
>
> Ok - makes sense.
>
>> If we
>> had applied Andrea's changes, it would have basically meant that
>> *all*
>> future doc updates would need to be manually done as well, as the
>> automated system we had planned would no longer be useful. That's a
>> big downside.
>
> Perphaps you don't see the value in Andrea's (handcrafted) work...
>
> Everything he has done can be extracted to metadata..
>
> (sphinx generates from metadata)
>
> It can all merged with an automated documentation generation process..
This is true when looking at the problem at a very high-level view,
but in our specific case, *not* having that metadata actually has
meaning when automatically generating docs. (It means that it's okay
to use the C++ docs.) If, like in Andrea's approach, all the
docstrings are manually defined at the wxPython level, then our
automated scripts will never know when it's okay to use the C++ docs.
>> Had Andrea bothered to consult wxPython-dev or ask Robin directly
>> before he went and did all this work, he'd have known all about this
>> issue before putting his time and effort into it.
>
> But he correctly identified that the problem with the documentation
> is the lack of any human touch..
They didn't lack any human touch, they lacked enough humans who could
spend enough time touching them. :-) The problem is that on a
volunteer project, you can't count "asking people to police the C++
docs daily" as a reliable solution that will work year in and year
out. It will lead to periods of doc updates followed by periods of
stagnation.
>> However, I think
>> even Robin only learned about Andrea's work at the same time everyone
>> else did, which was when he posted his finished product to wxPython-
>> users. If Andrea had really been concerned about getting his work
>> accepted and part of the official project to help all current and
>> future wxPythoneers, all it would have taken would have been for him
>> to contact wxPython-dev or wxPython-users (or just Robin) beforehand,
>> see what others were working on, and collaborate with them so we
>> could
>> all work together to get to the finish line sooner. I don't really
>> see
>> why he didn't do so, as it seems a fairly obvious and logical thing
>> to
>> do IMHO.
>
> History shows that what he has done has been rejected...
>
> If he had asked in the first place - the outcome would have been that
> his offer of help would have been rejected - I'm very sure.
Well, we'll never know the road not taken, but I'm almost certain it
would have turned out better for everyone involved had he done so. I
have for some time been keenly interested in getting the wxPython docs
up to speed, and I'd have been happy to work with him to come up with
a solution everyone would have been happy with, FWIW. (In fact, I'm
pretty sure he used some of my initial scripts aimed towards improving
the docs when he created the Sphinx docs!)
Yes, and Doxygen actually outputs XML files full of metadata that we
can use. On trunk, you can generate the xml docs by running the
following command:
docs/doxygen/regen.sh xml
(of course, Doxygen should be installed and on the path)
This script here is capable of extracting that metadata in those
Doxygen XML files into Python objects:
http://trac.wxwidgets.org/browser/wxWidgets/trunk/docs/doxygen/scripts/doxymlparser.py
See ClassDefinition and MethodDefinition for the Python objects that
get created.
From there, you just need to convert to the output format.
> We'll have two sets of data... (local) + (imported)....
>
> local is what is handwritten.. imported is what
> comes from wx
>
> Another file holds a master list of classes (in an xml file)...
>
> Merge the three lists... pull from imported where
> it isn't in local....
>
> Use restructed text.. as Andrea did..
>
> Do xml or cheetah transformations..
Agreed on the rest of these points.
> Having an automated system isn't a problem...
>
> What I would need to combine everybodies efforts is a
> branch on the svn tree... Same as everyone I have other
> bread and butter issues too..
>
> I am not promising anything overnight. But if we get
> the right structure in place.. I am not sure the task is so
> hard.
No, it's not really that hard, it just needs someone to help move
things forward. And if we work together, I'm fairly certain the
problem will actually get solved once and for good, in a way we could
all be happy with. :-)
Regards,
Kevin
> David
Chris Spencer
I've been using wxPython for 10 years now. In all of those 10 years,
the combination of the Demo and the wxWidgets documentation has
covered 95% or so of my needs. For the other 5%, I have dived into
the source code for wxPython to see what the CODE is doing.
While I'm not saying I am a typical case, I will say that I've never
really run into a situation I couldn't resolve by either
A) looking at the wxWidgets docs
B) looking at the Demo program
C) looking at the source code
or in the rarest cases...
D) asking a question of this mailing list or googling the problem.
What has vexed me on occasion is a lack of imagination on my part, or
not knowing a capability was a part of wxPython (so I reinvented the
wheel).
The book wxPython In Action (which I bought, BTW...good tutorial)
doesn't nearly go far enough. It's a good beginner's book, but it
doesn't handle edge-cases and advanced topics (nor SHOULD it).
One would think the wxPython wiki would fulfill the function of
documenting edge-cases and advanced topics, but it is so poorly
maintained, and so RARELY updated that it's not very useful.
For all the people who want a "human touch" on the documentation, may
I suggest that the wxPython wiki is in desperate need of maintenance
and new content.
There are dozens of web sites, tutorials, and wikis about "Ruby on
Rails"...and one poorly updated wxPython wiki. Maybe we can focus
some attention there?
Chris.
David Lyon
wrote:
> One would think the wxPython wiki would fulfill the function of
> documenting edge-cases and advanced topics, but it is so poorly
> maintained, and so RARELY updated that it's not very useful.
>
> For all the people who want a "human touch" on the documentation, may
> I suggest that the wxPython wiki is in desperate need of maintenance
> and new content.
Maybe you're right...
Maybe the wiki is a good place for edge-case examples and advanced
topics.
So maybe we can keep the idea of linking to a wiki page as a
discussion board location on any class - as an option to keep in mind
for the future.
As far as I know nobody has ever discouraged anybody from working
on the wiki.. but imho the class documentation is what needs the
to be the highest priority. Getting it to the point where it is
application developer friendly...
Regards
David
Fahlgren, Eric
> I've been using wxPython for 10 years now. In all of those 10 years,
> the combination of the Demo and the wxWidgets documentation has
> covered 95% or so of my needs. For the other 5%, I have dived into
> the source code for wxPython to see what the CODE is doing.
Exactly mirrors my feelings. Documentation is packed with lies, it's
always out of date. Only the code holds the truth, and it's pretty
trivial to navigate if you have a decent editor.
Eric
David Lyon
So...
on every class... a wiki link and a svn link to the current code...
Doesn't sound so bad.....
Robin Dunn
> For all the people who want a "human touch" on the documentation, may
> I suggest that the wxPython wiki is in desperate need of maintenance
> and new content.
>
> There are dozens of web sites, tutorials, and wikis about "Ruby on
> Rails"...and one poorly updated wxPython wiki. Maybe we can focus
> some attention there?
Work on the wiki is always welcome and appreciated.
Christopher Barker
> on every class... a wiki link and a svn link to the current code...
I like this, but a bunch of links to empty wiki pages doesn't look so
good either, so if this gets put in the docs, we really need to put the
effort in to populate the Wiki!
It's worth looking at what numpy/scipy has set up for their docs. They
are using Sphinx, and have set up a wiki-like system so that lot's of
folks can contribute. The posted additions get reviewed, then pulled in
to the official docs later. It's still an effort to get folks to
contribute, but it seems to be working pretty well:
http://docs.scipy.org/numpy/Front%20Page/