wxdevide-devs — Developer discussion for the project.

[Wxdevide-devs] Coding Guidelines

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

I have posted a basic guide on the wiki with the contents of 
discussions so far. To get more feedback on the guidelines I have a 
list of other projects guidelines. I particularly like some of the 
ideas of the NOX project.

http://pim.kde.org/development/coding-korganizer.php
http://developer.gnome.org/doc/guides/programming-guidelines/code-
style.html
http://trilinos.sandia.gov/packages/docs/r4.
0/packages/nox/doc/html/coding.html

Sof.T




See your new look Tiscali Homepage - http://www.tiscali.co.uk

___________________________________________________

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.

[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.

[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...>]

>
> - 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.

[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.

[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

[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

[Wxdevide-devs] svn access

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

Hi all,

There is an initial commit of code for this project at sf.

Could you all see if you can get it and do some small change to ensure 
you can commit.

I am not sure but I might have to enable everyone or something.

Best
Mal

[Wxdevide-devs] here two

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

try this again without crashing something :-)

Re: [Wxdevide-devs] I'm here

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

Ok. I'm here too. I think that makes Mal, Nuklear, Esteban, and me. Sof.T?
Anyone else that should be here?

-Tony


2008/9/27 Esteban Aguilar B. <nab...@ya...>

> Just to let you know I have joined the mailing lists.
> ------------------------------
>
> 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/
>
> -------------------------------------------------------------------------
> 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
>
>

[Wxdevide-devs] I'm here

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

Just to let you know I have joined the mailing lists.


      ____________________________________________________________________________________
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/

[Wxdevide-devs] I'm here

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

I'm now subscribed to the list.

-Tony

[Wxdevide-devs] FW: Testing

[Edward T. <edw...@ti...>]

 

 

-----Original Message-----
From: Edward Toovey [mailto:edw...@ti...] 
Sent: 27 September 2008 12:33
To: wxDevIde Developers (wxd...@li...)
Subject: Testing

 

Hi all just testing the new mailing list

 

Ed

[Wxdevide-devs] Testing

[Edward T. <edw...@ti...>]

Hi all just testing the new mailing list

 

Ed