wxdevide-devs — Developer discussion for the project.

Re: [Wxdevide-devs] Coding Guidelines

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

> What about component naming? Obviously the components have inherited
> their Delphi names but should there be a list of components and their
> "accepted" names? At the moment it is not important, but I envisage us
> continuing development, perhaps adding new dialogs, and these should
> follow the naming conventions for the rest of the project.
>
> While we are on the subject, should this be something we should add to
> wxdev-c++ initially? Offering a cbTemp1 instead of WxCheckBox1?
>

Yes, I think it's a good idea to convert the names and formatting now.


>
> > 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.
> >
>
> I would insist on changing
>
> Braces ("{}") which enclose a block should be aligned as follows:
>
>    if ( /*Something*/ ) // Yes!
>    {
>      i++;
>      j++;
>    }
>
>     if ( /*Something*/ ) { // Okay
>      i++;
>      j++;
>    }
>
>    if ( /*Something*/ ) // No!
>      {
>        i++;
>        j++;
>      }
>
> to
>
> Braces ("{}") which enclose a block should be aligned as follows:
>
>    if ( /*Something*/ ) // Yes!
>    {
>      i++;
>      j++;
>    }
>
>     if ( /*Something*/ ) { // No!
>      i++;
>      j++;
>    }
>
>    if ( /*Something*/ ) // No!
>      {
>        i++;
>        j++;
>      }
>
> That is
>
>    if ( /*Something*/ ) // Yes!
>    {
>      i++;
>      j++;
>    }
>
> should be the only acceptable form. Once we use Astyle then I think this
> is|--style=ansi
>
> Further Astyle options
>
> ||--indent=tab=4 // indent using tabs, and each tab is 4 spaces|
> |--brackets=break //should be covered in --style=ansi|produces the effect
> above
>
> |--indent-classes
> ||--indent-switches
> ||--indent-namespaces
> ||--indent-labels
> ||--indent-preprocessor
> ||--max-instatement-indent=40
> ||--pad=paren
>
>
> I'm not sure if I've missed anything important. We do need a config file
> for our use, so we only need to call astyle on the file itself. I had
> astyle as a tool in wxdev once, so it is certainly possible to use
> within the ide.
>

Agreed. I don't have any problems with these guidelines. The major thing is
to have an Astyle config file in SVN with these settings so that a developer
just has to remember to "astyle.exe -f wxdevide.config *.*" before
committing changes to SVN.


>
> Could I also suggest that developers keep two verions of the code on
> their systems? One which is a local copy of the svn head, and the second
> which is the actual work in progress copy. All changes should be
> transferred from the working copy to the svnhead copy before updating
> svn. This way we should be able to prevent updates to form files when
> all that has changed is the position of a component (unless that
> position/size change is warranted). We all know that to have the code
> generated we need to change something, and the easiest is to move a
> component, but that change doesn't have to be returned to svn.
>

I see your point here, but it's a little difficult logistically to do this.
I think what I might try is to keep two SVN directories, one called "MyCopy"
and one called "SVN_HEAD". Both will be linked to SVN HEAD, but (hopefully)
if I try to commit changes from MyCopy I'll catch the mistake beforehand. (I
wonder if there's a way to make Tortoise ignore my changes in the MyCopy
directory and just look for updates in SVN?) Otherwise, I can easily see the
MyCopy directory become out of sinc with other developers commits to SVN.


>
> Also (and unfortunately we don't seem to be able to do this currently)
> we need to have the designer place dialogs in a subdirectory. So for
> example the base directory should have all necessary files and the main
> form files, but that each dialog thereafter should be placed in its own
> folder. Thus each folder would contain three files (not yet decided
> about the xrc files) the .cpp/.h/.wxform files. Unfortunately I don't
> seem to be able to do this at the moment, but would like to see it
> happening.
>

You mean for both our source code and for the way the IDE behaves? So, for
example, the About dialog box in our source code will be place in a
subdirectory called "AboutFrm"? I suppose that makes sense (although it will
create a massive number of subdirectories).

One thing I thought of in regards to dialogs: We should build the filename
for the .h, .cpp, and .wxform into the class definition for the dialog. I
think right now we are always assuming that all 3 files will have the same
prototype name (e.g. AboutFrm.cpp, AboutFrm.h, AboutFrm.wxform). So it's
hardcoded that a .wxform file called AboutFrm.wxform will always try to
modify code in files called AboutFrm.cpp and AboutFrm.h. It would be nice to
be able to generalize this in case a user every wanted to rename the files.

-Tony

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

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.

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

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 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] I'm here

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

On 28/09/2008 02:39, Tony Reina wrote:
> Ok. I'm here too. I think that makes Mal, Nuklear, Esteban, and me. 
> Sof.T? Anyone else that should be here?
>


Sof.T is here too. What about KinMing? Did he want to join too?


-Mal

Re: [Wxdevide-devs] Coding Guidelines

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

By the way, have we changed the brace 
highlighting code anywhere? I  can remember that the matching braces 
were highlighted in inverse video at some point, which made them easier 
to see, but currently the matching brace is simply bolded. Or is this 
something quircky on my end? Or am I getting confused with another ide?Yes, I remember that too. Was that the scintilla stuff? Maybe we can enable it just in time for RC3 next week, along with the rest of the late minute fixes.


      ____________________________________________________________________________________
Premios MTV 2008¡En exclusiva! Fotos, nominados, videos, y mucho más! Mira aquí http://mtvla.yahoo.com/

Re: [Wxdevide-devs] Editor Plugins

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

speaking of editors, if we use wxsted, don't we have to put the notebook for
the editors in the editor plugin? i have not looked at it because of the
system trouble i was having, so i hope to do that soon. i would like to
finish the XRC tutorial this weekend first though.

Nuklear

On Fri, Oct 3, 2008 at 4:22 PM, Tony Reina <tb...@gm...> wrote:

> Good point. I hadn't thought of it before since if you right click on the
> form, the cut/copy/paste popup menu will work with the visual components. I
> guess we just overlooked making the menu options cut/copy/paste do the same.
>
> -Tony
>
>
>
> On Fri, Oct 3, 2008 at 12:28 PM, so...@ti... <so...@ti...>wrote:
>
>> In this IDE can we make the visual editor a member of editors? It
>> always annoyed me in the current IDE that the main frame menu edit
>> functions copy, cut, paste etc didn't work with the visual editor. I
>> would like to see these items call the functions in the current editor
>> and if applicable work with the text editor, visual editor or what ever
>> was open at the time.
>>
>> Sof.T
>>
>>
>>
>>
>> See your new look Tiscali Homepage - http://www.tiscali.co.uk
>>
>> ___________________________________________________
>>
>>
>> -------------------------------------------------------------------------
>> 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
>>
>
>
> -------------------------------------------------------------------------
> 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] Making this IDE an IDE for the majority

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

idea on the menu problem. for most plugins give an interface to one of
three? menus.
editor
plugins
settings
then they can keep things tidy and they put their stuff in a submenu

for some plugins we may need an interface to the main menu bar, like
versioning and editor. a general menubar interface maybe availible, but it
should be advised againt if it is.

i think feature requests is something to look at when the main work is done
and we want to make it better. as long as we make sure that any reasonable
access is given to a plugin for what it may need, a developer should be
capable of making a suitable implimentation from that. if that isn't good
enough for them, thay have the source code and can hack away at their hearts
content.

what is really needed in an ide i think wxDev-C++ has. and some more too.
multi compiler support. an integrated designer, many are stand alones.
versioning support. so we have a really good thing and the rest can be
plugged in.

Nuklear

Re: [Wxdevide-devs] Editor Plugins

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

Good point. I hadn't thought of it before since if you right click on the
form, the cut/copy/paste popup menu will work with the visual components. I
guess we just overlooked making the menu options cut/copy/paste do the same.

-Tony


On Fri, Oct 3, 2008 at 12:28 PM, so...@ti... <so...@ti...>wrote:

> In this IDE can we make the visual editor a member of editors? It
> always annoyed me in the current IDE that the main frame menu edit
> functions copy, cut, paste etc didn't work with the visual editor. I
> would like to see these items call the functions in the current editor
> and if applicable work with the text editor, visual editor or what ever
> was open at the time.
>
> Sof.T
>
>
>
>
> See your new look Tiscali Homepage - http://www.tiscali.co.uk
>
> ___________________________________________________
>
>
> -------------------------------------------------------------------------
> 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] Making this IDE an IDE for the majority

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

I second Esteban's cautions.

The major push initially should be to get an extensible platform which
behaves just like the current wxDev-C++. I have no problems with keeping in
mind a ToDo wish list of new ideas, but I don't want to get bogged down for
months trying to implement everything in one shot. Instead, the primary
focus should be on just getting a mirror of the current features/behavior,
just done so as generically and modularly as possible.

I figure if we make something that is truly extensible, there will be many
C++ developers out there willing to help with their pet project wishes.

-Tony


On Fri, Oct 3, 2008 at 2:53 PM, Esteban Aguilar B. <nab...@ya...>wrote:

> While I agree with the sentiment, lets not underestimate how much work we
> have ahead, just to replicate what we currently have. Some early feedback is
> good because it helps building the IDE with those ideas from the begining,
> but we have to be careful to not raise expectations of users too much too
> early...
>
> On a related subject, I've been thinking about what is better for us in
> terms of commenting to the public about wxDevIDE: on one hand, I think it is
> necesary to tell people at some point soon, what is going to happen with
> wxDevCPP, so they know we need some time to come up with the next version
> (wxDevIDE)... but on the other hand, it would be nice to announce wxDevIDE
> when we are close to deliver some bytes, as that could be percieved much
> better.
>
> --- El *vie 3-oct-08, so...@ti... <so...@ti...>* escribió:
>
> De: so...@ti... <so...@ti...>
> Asunto: [Wxdevide-devs] Making this IDE an IDE for the majority
> A: wxd...@li...
> Fecha: viernes, 3 octubre, 2008, 2:35 pm
>
>
> When we are building this IDE we want to appeal to the majority of
> users, as well as those with more esoteric wants. Is it worth going
> through the request lists of DevCpp and wxDev-C++ and making a list of
> what users have requested? At the same time is it worth posting to the
> wxDec-C++ forum and informing the users that we propose a new IDE based
> on wxDev-C++, but cross-platform and asking them what they want to see
> in the new IDE?
>
> I think by taking all these view into account we can build an IDE for
> all users from the start and have a better idea what we need to cater
> for in our design.
>
> Sof.T
>
>
>
>
> See your new look Tiscali Homepage - http://www.tiscali.co.uk
>
> ___________________________________________________
>
>
> -------------------------------------------------------------------------
> 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 worldhttp://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Wxdevide-devs mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/wxdevide-devs
>
>
> ------------------------------
>
> Premios MTV 2008
> ¡En exclusiva! Fotos, nominados, videos, y mucho más!br>Mira 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
>
>

Re: [Wxdevide-devs] Editor Plugins

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

Yes, as I commented on my proposal, there should be an "Editor" interface and a  BaseEditor class that implements it, and from wich most editors should inherit. This class probably will provide basic functionality for all these methods, which a designer editor could override. I'll try to publish a more specific and formal doc after the weekend, with these thougths.

--- El vie 3-oct-08, so...@ti... <so...@ti...> escribió:
De: so...@ti... <so...@ti...>
Asunto: [Wxdevide-devs] Editor Plugins
A: wxd...@li...
Fecha: viernes, 3 octubre, 2008, 2:28 pm

In this IDE can we make the visual editor a member of editors? It 
always annoyed me in the current IDE that the main frame menu edit 
functions copy, cut, paste etc didn't work with the visual editor. I 
would like to see these items call the functions in the current editor 
and if applicable work with the text editor, visual editor or what ever 
was open at the time.

Sof.T




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

___________________________________________________


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



      ____________________________________________________________________________________
¡Todo sobre Amor y Sexo!
La guía completa para tu vida en Mujer de Hoy.                       
http://mujerdehoy.telemundo.yahoo.com/

Re: [Wxdevide-devs] Making this IDE an IDE for the majority

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

While I agree with the sentiment, lets not underestimate how much work we have ahead, just to replicate what we currently have. Some early feedback is good because it helps building the IDE with those ideas from the begining, but we have to be careful to not raise expectations of users too much too early...On a related subject, I've been thinking about what is better for us in terms of commenting to the public about wxDevIDE: on one hand, I think it is necesary to tell people at some point soon, what is going to happen with wxDevCPP, so they know we need some time to come up with the next version (wxDevIDE)... but on the other hand, it would be nice to announce wxDevIDE when we are close to deliver some bytes, as that could be percieved much better.

--- El vie 3-oct-08, so...@ti... <so...@ti...> escribió:
De: so...@ti... <so...@ti...>
Asunto: [Wxdevide-devs] Making this IDE an IDE for the majority
A: wxd...@li...
Fecha: viernes, 3 octubre, 2008, 2:35 pm

When we are building this IDE we want to appeal to the majority of 
users, as well as those with more esoteric wants. Is it worth going 
through the request lists of DevCpp and wxDev-C++ and making a list of 
what users have requested? At the same time is it worth posting to the 
wxDec-C++ forum and informing the users that we propose a new IDE based 
on wxDev-C++, but cross-platform and asking them what they want to see 
in the new IDE?

I think by taking all these view into account we can build an IDE for 
all users from the start and have a better idea what we need to cater 
for in our design.

Sof.T




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

___________________________________________________


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



      ____________________________________________________________________________________
Premios MTV 2008¡En exclusiva! Fotos, nominados, videos, y mucho más! Mira aquí http://mtvla.yahoo.com/

Re: [Wxdevide-devs] Making this IDE an IDE for the majority

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

On 03/10/2008 21:35, so...@ti... wrote:
> When we are building this IDE we want to appeal to the majority of
> users, as well as those with more esoteric wants. Is it worth going
> through the request lists of DevCpp and wxDev-C++ and making a list of
> what users have requested?

Very much so I believe.

> At the same time is it worth posting to the
> wxDec-C++ forum and informing the users that we propose a new IDE based
> on wxDev-C++, but cross-platform and asking them what they want to see
> in the new IDE?
>    

Sounds good, but it should stress that it will attempt to keep the look 
and feel of wxDev as much as possible, so a complete redesign is really 
out of the question. But we should be open to our users.

> I think by taking all these view into account we can build an IDE for
> all users from the start and have a better idea what we need to cater
> for in our design.

I agree, but it might need to become a series of polls, depending upon 
whether there are competing ideas/requests. Although it might be 
possible to take al the requests and simply place them on a poll at the 
forum, and see which requests get the most hits. We should be wary that 
it doesn't grow to be an unmanageable project. Certainly we need to get 
the design right, but we don't want the wish list to grow out of all 
proportion and try and meet all desires at the beginning.

Best
Mal

Re: [Wxdevide-devs] Editor Plugins

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

On 03/10/2008 21:28, so...@ti... wrote:
> In this IDE can we make the visual editor a member of editors? It
> always annoyed me in the current IDE that the main frame menu edit
> functions copy, cut, paste etc didn't work with the visual editor. I
> would like to see these items call the functions in the current editor
> and if applicable work with the text editor, visual editor or what ever
> was open at the time.
>
>    

I agree. It makes the most sense that the cut/copy/paste commands (and 
any other applicable commands) work in whatever editor is open at the 
time. It should be trivial to detect if a component is selected 
currently and perform any command accordingly. All that really needs 
doing is to ensure that the key/shortcut  mapping remains consistent 
across all editors.

Best
Mal

[Wxdevide-devs] Making this IDE an IDE for the majority

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

When we are building this IDE we want to appeal to the majority of 
users, as well as those with more esoteric wants. Is it worth going 
through the request lists of DevCpp and wxDev-C++ and making a list of 
what users have requested? At the same time is it worth posting to the 
wxDec-C++ forum and informing the users that we propose a new IDE based 
on wxDev-C++, but cross-platform and asking them what they want to see 
in the new IDE?

I think by taking all these view into account we can build an IDE for 
all users from the start and have a better idea what we need to cater 
for in our design.

Sof.T




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

___________________________________________________

[Wxdevide-devs] Editor Plugins

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

In this IDE can we make the visual editor a member of editors? It 
always annoyed me in the current IDE that the main frame menu edit 
functions copy, cut, paste etc didn't work with the visual editor. I 
would like to see these items call the functions in the current editor 
and if applicable work with the text editor, visual editor or what ever 
was open at the time.

Sof.T




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

___________________________________________________

[Wxdevide-devs] CVS/SVN plugin?

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

Hi All,

Having just spent the morning "externalising my aggression" (or as I 
like to call it "stripping the wallpaper"), my thoughts return to wxDev-IDE.

Specifically, the source code revision control. I assume that the IDE 
will be as much as possible plugin based. So the question begs: do we 
add a (Manage) Plugin(s) Top level menu and expect that ALL plugins 
(even so far as the editor component?) register themselves here or do we 
keep a Version Control top level menu and expect the CVS/SVN/GIT/...  
plugins to register here?

Has anyone done any further thinking on the interface per se?

Having the plugins under a suitable Top Level Menu does mean that we 
would (possibly) need to create a top level menu for all types of plugin 
(where does Astyle go?) or should we say that in the case of Version 
Control we have a specific TLM and the rest have to go under a Manage 
Plugins TLM?

Much to think about, we have to get the interface as right as we can!

Best
Mal

Re: [Wxdevide-devs] Coding Guidelines

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

>
>
> I was once pointed to an "elastic tabs"idea once, the idea being that
> all tabs were lined up, and not just at the 4 char boundary.
> http://nickgravgaard.com/elastictabstops/
> That looked interesting, I wouldn't mind seeing that in the ide.
>
>
Actually, when I read "elastic tabs" I immediately thought of code folding.
As long as we have code folding when we are coding, then my point is moot.
The developer just needs to fold the code and the stuff in between is
hidden. So it won't be hard to figure out in that case.

Nothing to see here, move along...

-Tony

Re: [Wxdevide-devs] Coding Guidelines

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

On 03/10/2008 07:15, Tony Reina wrote:
>
>     > For if, else, while and similar statements put the brackets on the
>     > same line as the statement (this makes it easier to see if the
>     IDE has
>     > a matching braces tool)
>
>     You want
>
>        if ( /*Something*/ ) { //YES
>          i++;
>          j++;
>        }
>
>
> I'm willing to concede the point to you.

What's wrong? Don't like Southern Comfort? :)
>  The reason I prefer it the former way is because on the trailing 
> bracket, it is often hard to tell which starting bracket it goes with. 
> For example,
> if (Something) { //YES
> if (SomethingElse) {
> if (SomethingOther) {
> ... lots of lines of code, many with other embedded brackets...
> }
> }
> } // END YES
> If there are, say, 3 or 4 embedded if-then brackets, it may be hard to 
> tell what the  //END YES bracket goes with. In many IDEs, however, 
> there's a brace matching tool which shows the matching brace in the 
> command line. In my case, it would show:
> if (Something) {YES
> in your case, it would show:
> {
> So I'm just pointing out that in my style you get more info on the 
> matching brace.

What tool does it this way? I'd like to take a look.

I understand what you're saying here, but  if my style was enforced, 
(and this is purely personal opinion here) when viewing the source with 
several embedded if then stuff


if (some condition)
{
     if (some other condition)
     {
         if (yet another condition)
         {
         }
     }
}

and the reader only has to follow the brace up or down to find the 
associated brace and or condition.

Unfortunately wxDev at the moment only highlights the brace itself, 
which is unfortunate, since I can see the advantage of highlighting the 
complete line including condition. By the way, have we changed the brace 
highlighting code anywhere? I  can remember that the matching braces 
were highlighted in inverse video at some point, which made them easier 
to see, but currently the matching brace is simply bolded. Or is this 
something quircky on my end? Or am I getting confused with another ide?

> Perhaps a happy medium would be to use your method, but require 
> developers to add comments to their braces (both beginning and end).
> e.g.
> if (Something) // YES
> { // Begin "if (Something)"
> ... code ...
> } //End "if (Something)"


I can go along with this, although I can see the code getting crowded, 
unless we enforce a wide space (say 3 tabs worth) between the brace and 
the comment.

if (Something) // YES
{             // Begin "if (Something)"
... code ...
}             //End "if (Something)"

I was once pointed to an "elastic tabs"idea once, the idea being that 
all tabs were lined up, and not just at the 4 char boundary. 
http://nickgravgaard.com/elastictabstops/
That looked interesting, I wouldn't mind seeing that in the ide.

Best
Mal

Re: [Wxdevide-devs] Coding Guidelines

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

> > For if, else, while and similar statements put the brackets on the
> > same line as the statement (this makes it easier to see if the IDE has
> > a matching braces tool)
>
> You want
>
>    if ( /*Something*/ ) { //YES
>      i++;
>      j++;
>    }
>
>
> I'm willing to concede the point to you.

 The reason I prefer it the former way is because on the trailing bracket,
it is often hard to tell which starting bracket it goes with. For example,

if (Something) { //YES

if (SomethingElse) {

if (SomethingOther) {

... lots of lines of code, many with other embedded brackets...

}

}

} // END YES


If there are, say, 3 or 4 embedded if-then brackets, it may be hard to tell
what the  //END YES bracket goes with. In many IDEs, however, there's a
brace matching tool which shows the matching brace in the command line. In
my case, it would show:

if (Something) {YES

in your case, it would show:

{

So I'm just pointing out that in my style you get more info on the matching
brace.

Perhaps a happy medium would be to use your method, but require developers
to add comments to their braces (both beginning and end).

e.g.

if (Something) // YES
{ // Begin "if (Something)"

... code ...

} //End "if (Something)"


-Tony

Re: [Wxdevide-devs] Coding Guidelines

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

On 03/10/2008 02:16, Tony Reina wrote:
> That's a nice start. I'd like to add:
>
> C++ header files end in |.H| and source files end in |.C|pp

Agreed.

>
> Each file should begin with the $Id tag, original author, and license tag

Agreed, I'll go through the current source and add them.

>
> Every include file must contain a mechanism that prevents multiple 
> inclusions of the file. For example, the following should follow the 
> header information for the |NOX_Abstract_Vector.H| header file.
> #ifndef NOX_ABSTRACT_VECTOR_H
> #define NOX_ABSTRACT_VECTOR_H
>
> /...body of include file goes here.../
>
> #endif
>    

Agreed.

>
> If the arguments of a function don't fit into the 80 chars, start a 
> new line and align the additional arguments with the first one.
Agreed. I think  this might be done with |--indent-preprocessor or 
||--max-instatement-indent=# |but 'm not sure. We'll have to do some 
experimentation I think.

>
> For if, else, while and similar statements put the brackets on the 
> same line as the statement (this makes it easier to see if the IDE has 
> a matching braces tool)

You want

    if ( /*Something*/ ) { //YES
      i++;
      j++;
    }


Here is the first stumbling block

I much prefer

    if ( /*Something*/ ) // Yes!
    {
      i++;
      j++;
    }


I much prefer to see the braces, and you can still check if the brace 
matcher works. Now let's see. You live in America, I live in the 
Netherlands, is there a boat somewhere in the Pacific with a decent bar?

Of course this is trivial and can be achieved by having two astyle 
config files, a global one for the svn code, and a local one for the 
working copy, we just have to enforce the svn config file before a merge 
and cpomit. Your local one can be what you want.

>
> Each public function must have a Doxygen compatible comment in the header

Agreed.

>
> Use true and false instead of TRUE and FALSE.
>

Agreed.

Best regards
Mal

Re: [Wxdevide-devs] Coding Guidelines

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

That's a nice start. I'd like to add:

C++ header files end in .H and source files end in .Cpp

Each file should begin with the $Id tag, original author, and license tag

Every include file must contain a mechanism that prevents multiple
inclusions of the file. For example, the following should follow the header
information for the NOX_Abstract_Vector.H header file.

#ifndef NOX_ABSTRACT_VECTOR_H
#define NOX_ABSTRACT_VECTOR_H

*...body of include file goes here...*

#endif


If the arguments of a function don't fit into the 80 chars, start a new line
and align the additional arguments with the first one.

For if, else, while and similar statements put the brackets on the same line
as the statement (this makes it easier to see if the IDE has a matching
braces tool)

Each public function must have a Doxygen compatible comment in the header

Use true and false instead of TRUE and FALSE.

-Tony




On Thu, Oct 2, 2008 at 12:55 PM, so...@ti... <so...@ti...>wrote:

> 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://developer.gnome.org/doc/guides/programming-guidelines/code-style.html>
> http://trilinos.sandia.gov/packages/docs/r4.
> 0/packages/nox/doc/html/coding.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
>
> ___________________________________________________
>
>
> -------------------------------------------------------------------------
> 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] Coding Guidelines

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

On 02/10/2008 21:55, so...@ti... wrote:
> I have posted a basic guide on the wiki with the contents of
> discussions so far.
What about component naming? Obviously the components have inherited 
their Delphi names but should there be a list of components and their 
"accepted" names? At the moment it is not important, but I envisage us 
continuing development, perhaps adding new dialogs, and these should 
follow the naming conventions for the rest of the project.

While we are on the subject, should this be something we should add to 
wxdev-c++ initially? Offering a cbTemp1 instead of WxCheckBox1?


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

I would insist on changing

Braces ("{}") which enclose a block should be aligned as follows:

    if ( /*Something*/ ) // Yes!
    {
      i++;
      j++;
    }

    if ( /*Something*/ ) { // Okay
      i++;
      j++;
    }

    if ( /*Something*/ ) // No!
      {
        i++;
        j++;
      }

to

Braces ("{}") which enclose a block should be aligned as follows:

    if ( /*Something*/ ) // Yes!
    {
      i++;
      j++;
    }

    if ( /*Something*/ ) { // No!
      i++;
      j++;
    }

    if ( /*Something*/ ) // No!
      {
        i++;
        j++;
      }

That is

    if ( /*Something*/ ) // Yes!
    {
      i++;
      j++;
    }

should be the only acceptable form. Once we use Astyle then I think this is|--style=ansi

Further Astyle options

||--indent=tab=4 // indent using tabs, and each tab is 4 spaces|
|--brackets=break //should be covered in --style=ansi|produces the effect above

|--indent-classes
||--indent-switches
||--indent-namespaces
||--indent-labels
||--indent-preprocessor
||--max-instatement-indent=40
||--pad=paren


I'm not sure if I've missed anything important. We do need a config file 
for our use, so we only need to call astyle on the file itself. I had 
astyle as a tool in wxdev once, so it is certainly possible to use 
within the ide.

Could I also suggest that developers keep two verions of the code on 
their systems? One which is a local copy of the svn head, and the second 
which is the actual work in progress copy. All changes should be 
transferred from the working copy to the svnhead copy before updating 
svn. This way we should be able to prevent updates to form files when 
all that has changed is the position of a component (unless that 
position/size change is warranted). We all know that to have the code 
generated we need to change something, and the easiest is to move a 
component, but that change doesn't have to be returned to svn.

Also (and unfortunately we don't seem to be able to do this currently) 
we need to have the designer place dialogs in a subdirectory. So for 
example the base directory should have all necessary files and the main 
form files, but that each dialog thereafter should be placed in its own 
folder. Thus each folder would contain three files (not yet decided 
about the xrc files) the .cpp/.h/.wxform files. Unfortunately I don't 
seem to be able to do this at the moment, but would like to see it 
happening.

I'll probably think of something later, but these are my initial thoughts.

Best regards
Mal
|