wxdevide-devs

[Wxdevide-devs] Which Help File Format and other questions.

[Malcolm N. <m.n...@wa...>]

Hi All,

Since we are moving to wxWidgets, should we also move the help file to 
wxHelp format? This has my vote, since we need to generate help for all 
platforms.

Also, assuming we are, I would suggest that the help is written as we go 
along, ensuring that we can correctly link to subjects as we move along.

I assume that we can re-use a lot of information from the old help file, 
replacing screen shots as we go for example. We need to ensure that 
context help works as expected also.

Do we support the "What's this" help under windows? Or do we insist that 
the program works exactly the same on all platforms?

The images for the new look (as used by wxdevcpp) need to be located and 
added to svn. I would also suggest giving this theme a different name 
and allowing the user to select between the images currently within the 
folder "new look" and those we actually use for the new look in wxdev.

Are we going to go the sizer route for dialog design? This gets my vote, 
as well as turning on wxDefaultPosition/wxDefaultSize in the designer, 
it makes the dialogs look better when designed with sizers.

We need to decide on a standard Astyle style for our code. I assume we 
all have a preference as to how we like our code to look, so we need to 
agree on a standard from the beginning.

I have looked at Sof.T's SkinDoc2 project, and it looks as though the 
form designer there could be used to replace our designer. (Ed could you 
tell me the difference between the old designer and the new designer - 
does it suffer from the same problem we do where it grows beyond the 
confines of the screen and becomes unmanageable- need scroll bars for 
example?

Just some food for thought

Mal

Re: [Wxdevide-devs] Which Help File Format and other questions.

[Sof.T <so...@ti...>]

I have no particular preference for help formats as long as all
platforms are supported. I wouldn't mind seeing a more integrated help
system a bit like kdevelop, but I guess that could be implemented as
another plugin.

Personally I think there is no point in insisting that the program is
exactly the same under all platforms. There is little point in crippling
the program just to make it exactly alike. If it is possible to
implement a killer feature on one platform that is not possible on other
platforms then I think it should be implemented.

Will we be supporting themeing? While porting DevCpp I only got so far
in implementing the themeing, it seems that wxWidgets doesn't make it
easy for example to change the images of button in toolbars, maybe I am
wrong and just couldn't find the way to do it. For example you cant just
load the images from an image list and then change the image list over
for a new look. Though maybe the new wxAUI toolbar will be better or can
be adapted.

I vote sizers for everything it makes it much easier to go cross
platform.

For code styling I prefer a 4 space indent and lined up braces e.g.

void MyFunction()
{
    code
}

not

void MyFunction(){
    code
}

for me it makes it easier to see brace mismatching although it adds
extra lines to the code file.

What about function names do we go CamelCase, or lowercase for the first
letter or all lower case

MyFuction
myFuction
myfunction

Should we start a wiki page on developer guidelines? By the way has
anyone tried to use the wiki, it keeps telling me I need to login, when
I do it takes me to my sourceforge account page or it tells me I am
logged in, but that I still need to log in to edit anything.

The SkinDoc2 form designer could be altered quite easily to create a
form designer for wxDevIde. However it is Windows only since other
platforms don't support embedding of windows in windows, there are ways
around this, I planned to use the CurlyAnkles library under GTK and find
another solution for MacOS. The form designer uses scroll bars when the
form grows beyond the confines of the designer, my scrolling code needs
a little tweak as the scrollbars don't size correctly I think I know the
problem, but haven't implemented it yet.

Sof.T

-----Original Message-----
From: Malcolm Nealon [mailto:m.n...@wa...] 
Sent: 28 September 2008 10:51
To: wxdevide-devs
Subject: [Wxdevide-devs] Which Help File Format and other questions.

Hi All,

Since we are moving to wxWidgets, should we also move the help file to 
wxHelp format? This has my vote, since we need to generate help for all 
platforms.


Also, assuming we are, I would suggest that the help is written as we go

along, ensuring that we can correctly link to subjects as we move along.

I assume that we can re-use a lot of information from the old help file,

replacing screen shots as we go for example. We need to ensure that 
context help works as expected also.

Do we support the "What's this" help under windows? Or do we insist that

the program works exactly the same on all platforms?

The images for the new look (as used by wxdevcpp) need to be located and

added to svn. I would also suggest giving this theme a different name 
and allowing the user to select between the images currently within the 
folder "new look" and those we actually use for the new look in wxdev.

Are we going to go the sizer route for dialog design? This gets my vote,

as well as turning on wxDefaultPosition/wxDefaultSize in the designer, 
it makes the dialogs look better when designed with sizers.

We need to decide on a standard Astyle style for our code. I assume we 
all have a preference as to how we like our code to look, so we need to 
agree on a standard from the beginning.

I have looked at Sof.T's SkinDoc2 project, and it looks as though the 
form designer there could be used to replace our designer. (Ed could you

tell me the difference between the old designer and the new designer - 
does it suffer from the same problem we do where it grows beyond the 
confines of the screen and becomes unmanageable- need scroll bars for 
example?

Just some food for thought

Mal





------------------------------------------------------------------------
-
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the
world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Wxdevide-devs mailing list
Wxd...@li...
https://lists.sourceforge.net/lists/listinfo/wxdevide-devs

Re: [Wxdevide-devs] Which Help File Format and other questions.

[Esteban A. B. <nab...@ya...>]

I have no particular preference for help formats as long as all
platforms are supported. I wouldn't mind seeing a more integrated help
system a bit like kdevelop, but I guess that could be implemented as
another plugin.

Personally I think there is no point in insisting that the program is
exactly the same under all platforms. There is little point in crippling
the program just to make it exactly alike. If it is possible to
implement a killer feature on one platform that is not possible on other
platforms then I think it should be implemented.

Will we be supporting themeing? While porting DevCpp I only got so far
in implementing the themeing, it seems that wxWidgets doesn't make it
easy for example to change the images of button in toolbars, maybe I am
wrong and just couldn't find the way to do it. For example you cant just
load the images from an image list and then change the image list over
for a new look. Though maybe the new wxAUI toolbar will be better or can
be adapted.

I vote sizers for everything it makes it much easier to go cross
platform.


Agreed to everything. Now, about the designer for the end user, I think it still would be nice 
to have the option of the fixed-stuff crappy mode (just for quick projects).


For code styling I prefer a 4 space indent and lined up braces e.g.

void MyFunction()
{
    code
}

not

void MyFunction(){
    code
}

for me it makes it easier to see brace mismatching although it adds
extra lines to the code file.


Agreed.

What about function names do we go CamelCase, or lowercase for the first
letter or all lower case

MyFuction
myFuction
myfunction

I had some suggestions for current project not so long ago (most apply to C++):

- Use tabs for indentation. 
- I've seen in some editors that there are "different
tab sizes" (on Delphi for example you can choose the
tab size equivalent to spaces); I'm not sure how that
works but just in case, lets say we'll use a tab size
of 4 spaces.
- variables, intances start lower case.
- primitive types start lower case.
- Object, structs, enum types and the like,
capitalized.
- Method names capitalized (maybe its better to change this one to lower case first).
- spaces between most operators and operands (no
things like a+b=c). Exceptions could be the
parenthesis and semicolon.
- Word sepparation capitalizing (not using
underscore; or is it better the other way around?).




      ____________________________________________________________________________________
Yahoo! MTV Blog & Rock >¡Cuéntanos tu historia, inspira una canción y gánate un viaje a los Premios MTV! Participa aquí http://mtvla.yahoo.com/

Re: [Wxdevide-devs] Which Help File Format and other questions.

[Tony R. <tb...@gm...>]

>
> - Use tabs for indentation.
> - I've seen in some editors that there are "different
> tab sizes" (on Delphi for example you can choose the
> tab size equivalent to spaces); I'm not sure how that
> works but just in case, lets say we'll use a tab size
> of 4 spaces.
> - variables, intances start lower case.
> - primitive types start lower case.
> - Object, structs, enum types and the like,
> capitalized.
> - Method names capitalized (maybe its better to change this one to lower case first).
> - spaces between most operators and operands (no
> things like a+b=c). Exceptions could be the
> parenthesis and semicolon.
> - Word sepparation capitalizing (not using
> underscore; or is it better the other way around?).
>
>
> ------------------------------
>

I think with AStyle you can specify a formatting file. Can you build one
that we can just add to SVN? This way, the developer can just run AStyle
using that formatting file definition.

Also, can you add these suggestions to the wiki page under the AStyle
section?

Thanks.
-Tony

Re: [Wxdevide-devs] Which Help File Format and other questions.

[Tony R. <tb...@gm...>]

The wxHelp idea seems fine to me. I've posted the wiki pages so we can start
to add these specifics to it. I think it's good that we are starting to get
down to the nitty gritty regarding implementation.

I'm not sure I understand the sizer idea. Are you saying that we should use
sizers to implement the IDE? Or, are you saying that the user will be
required to use sizers in the wx RAD? I don't like the latter as it is
completely different from our current wx RAD behavior. I think most novice
users will try to add a wxButton to a wxFrame/wxDialog and get frustrated if
it doesn't immediately work because a sizer hadn't been added first. I
prefer the current behavior where the user has the choice to use sizers or
design "free-form".

As an important aside, I'd like to bring up the topic of developer
conflicts. Although I think we are all reasonable people, it is good that we
have a plan to handle the times where one developer strongly disagrees with
another about how something should work. I've run across this situation in
the past and it can lead to bad blood.

I have a proposal for handling conflicts, but welcome other ideas. I figure
there are 5 core developers right now (me, Nuklear, SofT, Esteban, and Mal).
For major policy/architecture resolutions, we just go with a simple majority
(so, at present, if you can convince 2 other core developers that you are
right, then you've got the 3 votes you need). In the case that the number of
core developers ever changes to an even number and a tie occurs, the tie
breaking vote is the core developer that's been here the longest. For the
present 5 core developers, I'd suggest that Nuklear is the lead developer
since he started the SF page and got the ball rolling. Next in line is SofT
who contributed the initial souce code to SVN. Next is Mal who commited the
first SVN source code. Then, Esteban who produced the first API docs. And
then me because I'm the only one left. So if we ever added/lost developers,
Nuklear would currently have the tie-breaker vote.

Perhaps all of this seems silly to bring up, but I thought we'd get it on
the table for discussion. Does anyone have a better plan?

-Tony

p.s. I think Nuklear and I currently have admin status on the website. It
is, of course, offered to any of the core developers who want it. Just let
one of us know if you want admin status.

On Sun, Sep 28, 2008 at 2:50 AM, Malcolm Nealon <m.n...@wa...> wrote:

> Hi All,
>
> Since we are moving to wxWidgets, should we also move the help file to
> wxHelp format? This has my vote, since we need to generate help for all
> platforms.
>
> Also, assuming we are, I would suggest that the help is written as we go
> along, ensuring that we can correctly link to subjects as we move along.
>
> I assume that we can re-use a lot of information from the old help file,
> replacing screen shots as we go for example. We need to ensure that
> context help works as expected also.
>
> Do we support the "What's this" help under windows? Or do we insist that
> the program works exactly the same on all platforms?
>
> The images for the new look (as used by wxdevcpp) need to be located and
> added to svn. I would also suggest giving this theme a different name
> and allowing the user to select between the images currently within the
> folder "new look" and those we actually use for the new look in wxdev.
>
> Are we going to go the sizer route for dialog design? This gets my vote,
> as well as turning on wxDefaultPosition/wxDefaultSize in the designer,
> it makes the dialogs look better when designed with sizers.
>
> We need to decide on a standard Astyle style for our code. I assume we
> all have a preference as to how we like our code to look, so we need to
> agree on a standard from the beginning.
>
> I have looked at Sof.T's SkinDoc2 project, and it looks as though the
> form designer there could be used to replace our designer. (Ed could you
> tell me the difference between the old designer and the new designer -
> does it suffer from the same problem we do where it grows beyond the
> confines of the screen and becomes unmanageable- need scroll bars for
> example?
>
> Just some food for thought
>
> Mal
>
>
>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Wxdevide-devs mailing list
> Wxd...@li...
> https://lists.sourceforge.net/lists/listinfo/wxdevide-devs
>

Re: [Wxdevide-devs] Which Help File Format and other questions.

[Malcolm N. <m.n...@wa...>]

On 28/09/2008 18:46, Tony Reina wrote:
> The wxHelp idea seems fine to me. I've posted the wiki pages so we can 
> start to add these specifics to it. I think it's good that we are 
> starting to get down to the nitty gritty regarding implementation.

Me too :)
>
> I'm not sure I understand the sizer idea. Are you saying that we 
> should use sizers to implement the IDE? Or, are you saying that the 
> user will be required to use sizers in the wx RAD?
I think we should be using sizers in the design of our dialogs. I 
suppose the ide won't matter as such, since it will be controlled by 
wxaui (so automatically sizer based). I meant that although our dialogs 
should look as much like the current ones as possible, that we should 
try to use sizers to have them look as well as we can on all platforms.

My only caveat (love that word) is that once the dialog has been 
designed as well as possible, that the sizers be "removed". By this I 
mean that the sizer border should be reduced to 1 or possibly 0, to 
remove any possible unneccessary padding of the dialog. But this is just 
my personal opinion.
> I don't like the latter as it is completely different from our current 
> wx RAD behavior. I think most novice users will try to add a wxButton 
> to a wxFrame/wxDialog and get frustrated if it doesn't immediately 
> work because a sizer hadn't been added first. I prefer the current 
> behavior where the user has the choice to use sizers or design 
> "free-form".
Agreed, but we have to make sure that the designer produces a visibly 
correct dialog when using sizers. To see what I mean, checkout the svn 
of wxdevide and take a look at the envirofrm.wxform file (using the svn 
build of wxdevcpp). This is designed using the current envirofrm as a 
design, as many names as possible were used from the delphi code, etc. 
Some borders were removed to make it look more like the delphi created 
dialog. However if you opern the form in wxdevcpp you will see that the 
dialog on generation, looks nothing  like the dialog in the designer. 
Also when using sizers, we have to enforce the use of wxDefaultPosition, 
I am not sue about wxDefaultSize but I believe so, otherwise the dialog 
looks freaky.

>
> As an important aside, I'd like to bring up the topic of developer 
> conflicts. Although I think we are all reasonable people, it is good 
> that we have a plan to handle the times where one developer strongly 
> disagrees with another about how something should work. I've run 
> across this situation in the past and it can lead to bad blood.
Don't worry, if there's bad blood I don't mind spilling someone's, 
besides I have a soldier in training that needs some exercise :)

>
> I have a proposal for handling conflicts, but welcome other ideas. I 
> figure there are 5 core developers right now (me, Nuklear, SofT, 
> Esteban, and Mal). For major policy/architecture resolutions, we just 
> go with a simple majority (so, at present, if you can convince 2 other 
> core developers that you are right, then you've got the 3 votes you 
> need). In the case that the number of core developers ever changes to 
> an even number and a tie occurs, the tie breaking vote is the core 
> developer that's been here the longest. For the present 5 core 
> developers, I'd suggest that Nuklear is the lead developer since he 
> started the SF page and got the ball rolling. Next in line is SofT who 
> contributed the initial souce code to SVN. Next is Mal who commited 
> the first SVN source code. Then, Esteban who produced the first API 
> docs. And then me because I'm the only one left. So if we ever 
> added/lost developers, Nuklear would currently have the tie-breaker vote.
I have a better idea, the two in conflict sit down with a bottle of 
Southern Comfort and take turns drinking a glass, the one who remains 
coherent the longest wins. ;)

>
> Perhaps all of this seems silly to bring up, but I thought we'd get it 
> on the table for discussion. Does anyone have a better plan?

Not silly, especially since we are spread around the globe. It is better 
to have a plan in place in case anything undesireable happens.
>
> p.s. I think Nuklear and I currently have admin status on the website. 
> It is, of course, offered to any of the core developers who want it. 
> Just let one of us know if you want admin status.
I already have admin rights.

Best Regards
Mal

Re: [Wxdevide-devs] Which Help File Format and other questions.

[Tony R. <tb...@gm...>]

>
> I have a better idea, the two in conflict sit down with a bottle of
> Southern Comfort and take turns drinking a glass, the one who remains
> coherent the longest wins. ;)
>
>
You sure you're not originally from New Orleans? ;>)

-Tony

Re: [Wxdevide-devs] Which Help File Format and other questions.

[Nuklear Z. <nuk...@gm...>]

i hope no bad blood spawns from this. i don't believe it should, we have all
worked together and we know each other pretty well. (in this enviornment) so
there is no reason to believe that will happen. if it does i expect it to be
someone who joins later and then wants to demand control.

i think that the seniority model works except that it needs to be geard a
little more to experience. not say time we've been programmers, but the
experience we have on areas of the code. so already we know that Edward
built the Skindoc designer and converted all the code in svn currently. not
that all of it will be used maybe, but he knows it better than the rest of
us. Esteban took care of the plugin system so he knows more than us there.
even if others have worked on a plugin system, he also knows what it takes
for an ide specifically and more specifically for what dev has in it. you
get my drift. so since we are all starting here at the same time, it makes
the most sense that the developer who knows the area in conflict best have
the highest dibs. but majority still rules.

as for newer comming devs, they never get quite the rights we do. not that
there is going to need to be a seperation, but we all created this from the
beggining and have experience with the last project, this is somewhat a
continuance of. so they just don't have the experience is what it boils down
to.

also if someone has to take a leave for a long time, they need to be
decrimented in powers upon return till they can catch up with any changes
they are not farmiliar with. hopefully nobody has troubles for months at a
time. ;)

that is how i feel. i can't comfortably vote on a plugin approach since i
don't know anything about them. i can suggest what is availible to the api
though. so an example why seniority over experience in the codebase is my
opinion.

also the basic idea behind what we are doing needs to be looked at (that
goes without saying obviously.) so will it screw up the Dev feel? if it is
removable, it doesn't have to.

Nuklear

Re: [Wxdevide-devs] Which Help File Format and other questions.

[Malcolm N. <m.n...@wa...>]

On 29/09/2008 01:57, Nuklear Zelph wrote:
> hopefully nobody has troubles for months at a time. ;)
>

You are obviously not aware of my family problems :-(

Still it looks as though the largest part is almost finished :-)

Mal

Re: [Wxdevide-devs] Which Help File Format and other questions.

[Tony R. <tb...@gm...>]

On Sun, Sep 28, 2008 at 4:57 PM, Nuklear Zelph <nuk...@gm...>wrote:

> i hope no bad blood spawns from this. i don't believe it should, we have
> all worked together and we know each other pretty well. (in this
> enviornment) so there is no reason to believe that will happen. if it does i
> expect it to be someone who joins later and then wants to demand control.
>

I think that's right. I had brought up the issue just to make sure we had
some sort of a system we could all agree on.


>
> i think that the seniority model works except that it needs to be geard a
> little more to experience. not say time we've been programmers, but the
> experience we have on areas of the code. so already we know that Edward
> built the Skindoc designer and converted all the code in svn currently. not
> that all of it will be used maybe, but he knows it better than the rest of
> us. Esteban took care of the plugin system so he knows more than us there.
> even if others have worked on a plugin system, he also knows what it takes
> for an ide specifically and more specifically for what dev has in it. you
> get my drift. so since we are all starting here at the same time, it makes
> the most sense that the developer who knows the area in conflict best have
> the highest dibs. but majority still rules.
>

I for one will base my vote on who has the most experience with the
particular issue in question. For example, if it's an issue with the
Skindoc, then I'll be listening to Sof.T. more than to Mal (especially if
Mal's had too many Southern Comforts ;>).


>
> as for newer comming devs, they never get quite the rights we do. not that
> there is going to need to be a seperation, but we all created this from the
> beggining and have experience with the last project, this is somewhat a
> continuance of. so they just don't have the experience is what it boils down
> to.
>

Yes, developers that come later I think will "move up the ranks". In my
opinion, they should first be running their patches/bugs fixes/etc. through
the core developers. Once we are satisfied that the person knows what they
are doing, then we'd grant them their own SVN access. Admins/core developers
should be limited to people who have shown their commitment to the project.

Nevertheless, I think that whenever a developer (core or not) commits
significant changes to SVN, that they should let the list know about it and
give a brief description of the changes. Of course, simple bug fixes don't
need such formaility. The rule of thumb: If you think someone will object to
your commit, then ask first.



>
> also if someone has to take a leave for a long time, they need to be
> decrimented in powers upon return till they can catch up with any changes
> they are not farmiliar with. hopefully nobody has troubles for months at a
> time. ;)
>

Agreed.


>
>
-Tony

Re: [Wxdevide-devs] Which Help File Format and other questions.

[Malcolm N. <m.n...@wa...>]

On 05/10/2008 19:51, Tony Reina wrote:
>
>
> On Sun, Sep 28, 2008 at 4:57 PM, Nuklear Zelph <nuk...@gm... 
> <mailto:nuk...@gm...>> wrote:
>
>
>     i think that the seniority model works except that it needs to be
>     geard a little more to experience. not say time we've been
>     programmers, but the experience we have on areas of the code. so
>     already we know that Edward built the Skindoc designer and
>     converted all the code in svn currently. not that all of it will
>     be used maybe, but he knows it better than the rest of us. Esteban
>     took care of the plugin system so he knows more than us there.
>     even if others have worked on a plugin system, he also knows what
>     it takes for an ide specifically and more specifically for what
>     dev has in it. you get my drift. so since we are all starting here
>     at the same time, it makes the most sense that the developer who
>     knows the area in conflict best have the highest dibs. but
>     majority still rules.
>
>
> I for one will base my vote on who has the most experience with the 
> particular issue in question. For example, if it's an issue with the 
> Skindoc, then I'll be listening to Sof.T. more than to Mal (especially 
> if Mal's had too many Southern Comforts ;>).
You can never have too many Southern Comforts. :-D

>
>
>     as for newer comming devs, they never get quite the rights we do.
>     not that there is going to need to be a seperation, but we all
>     created this from the beggining and have experience with the last
>     project, this is somewhat a continuance of. so they just don't
>     have the experience is what it boils down to.
>
>
> Yes, developers that come later I think will "move up the ranks". In 
> my opinion, they should first be running their patches/bugs fixes/etc. 
> through the core developers. Once we are satisfied that the person 
> knows what they are doing, then we'd grant them their own SVN access. 
> Admins/core developers should be limited to people who have shown 
> their commitment to the project.

I think that this is more or less a standard method on Open Source 
projects.

>
> Nevertheless, I think that whenever a developer (core or not) commits 
> significant changes to SVN, that they should let the list know about 
> it and give a brief description of the changes. Of course, simple bug 
> fixes don't need such formaility. The rule of thumb: If you think 
> someone will object to your commit, then ask first.

But we do need to actively appraise these changes. I have unfortunately 
seen that a lot of work has gone into something only to have it vetoed 
much later than needed. (not speaking necessarily of this project) I 
think to reduce this as much, then we have to enforce a time scale. I am 
aware that not everyone spends as much time with the computer as I (not 
that I am programming the whole time) so waiting for longer than a day 
for a reply from me is usually rare (except when SF/my provider screws 
around - I received a mail today that I mailed to a list Friday), but we 
do have to at least try to monitor the mailings daily. Patches should be 
examined, and tested. There is a lot we can do to make developing this a 
pleasurable fun experience. We should try to keep it that way.

Best
Mal

Re: [Wxdevide-devs] Which Help File Format and other questions.

[Tony R. <tb...@gm...>]

>
>
> > Nevertheless, I think that whenever a developer (core or not) commits
> > significant changes to SVN, that they should let the list know about
> > it and give a brief description of the changes. Of course, simple bug
> > fixes don't need such formaility. The rule of thumb: If you think
> > someone will object to your commit, then ask first.
>
> But we do need to actively appraise these changes. I have unfortunately
> seen that a lot of work has gone into something only to have it vetoed
> much later than needed. (not speaking necessarily of this project) I
> think to reduce this as much, then we have to enforce a time scale. I am
> aware that not everyone spends as much time with the computer as I (not
> that I am programming the whole time) so waiting for longer than a day
> for a reply from me is usually rare (except when SF/my provider screws
> around - I received a mail today that I mailed to a list Friday), but we
> do have to at least try to monitor the mailings daily. Patches should be
> examined, and tested. There is a lot we can do to make developing this a
> pleasurable fun experience. We should try to keep it that way.
>
>
No, I don't think it needs to be appraised unless it's a major change in how
the architecture looks or how the IDE behaves (e.g. API changes, config file
changes, etc.). What I was thinking of is just an email message (or maybe
some sort of developer forum) where we post a little detail on the change.
My thought is that sometimes SVN comments are pretty limited and there might
not be enough room in them to fully explain how something new works. For
example, in an API change, you really want a more detailed message to the
developers so that everyone is aware of the change. Or, if there's a major
bug fix, it might be useful to other developers to know that something was
coded wrong (e.g. in wxDev-C++ we found that the plugins count variable
wasn't equal to 1 when it should have been-- this might not just affect the
specific code that was patched; with that knowledge Esteban might be
prompted to check all of the occurrences of the variable to make sure that
there aren't other lingering bugs associated with it).

-Tony

Re: [Wxdevide-devs] Which Help File Format and other questions.

[Tony R. <tb...@gm...>]

I should add that I think all of the core developers already do these things
well. I just meant to bring up the issue for posterity. Also, it helps me
when I have to compile a changelog for a forthcoming release (and can't
remember what changes we made since the last release 12 months ago).

The bottom line is that the more communication we have about what is being
done and what has been done, the better.

-Tony


On Sun, Oct 5, 2008 at 1:02 PM, Tony Reina <tb...@gm...> wrote:

>
>> > Nevertheless, I think that whenever a developer (core or not) commits
>> > significant changes to SVN, that they should let the list know about
>> > it and give a brief description of the changes. Of course, simple bug
>> > fixes don't need such formaility. The rule of thumb: If you think
>> > someone will object to your commit, then ask first.
>>
>> But we do need to actively appraise these changes. I have unfortunately
>> seen that a lot of work has gone into something only to have it vetoed
>> much later than needed. (not speaking necessarily of this project) I
>> think to reduce this as much, then we have to enforce a time scale. I am
>> aware that not everyone spends as much time with the computer as I (not
>> that I am programming the whole time) so waiting for longer than a day
>> for a reply from me is usually rare (except when SF/my provider screws
>> around - I received a mail today that I mailed to a list Friday), but we
>> do have to at least try to monitor the mailings daily. Patches should be
>> examined, and tested. There is a lot we can do to make developing this a
>> pleasurable fun experience. We should try to keep it that way.
>>
>>
> No, I don't think it needs to be appraised unless it's a major change in
> how the architecture looks or how the IDE behaves (e.g. API changes, config
> file changes, etc.). What I was thinking of is just an email message (or
> maybe some sort of developer forum) where we post a little detail on the
> change. My thought is that sometimes SVN comments are pretty limited and
> there might not be enough room in them to fully explain how something new
> works. For example, in an API change, you really want a more detailed
> message to the developers so that everyone is aware of the change. Or, if
> there's a major bug fix, it might be useful to other developers to know that
> something was coded wrong (e.g. in wxDev-C++ we found that the plugins count
> variable wasn't equal to 1 when it should have been-- this might not just
> affect the specific code that was patched; with that knowledge Esteban might
> be prompted to check all of the occurrences of the variable to make sure
> that there aren't other lingering bugs associated with it).
>
> -Tony
>
>
>