wxdevide-devs — Developer discussion for the project.

Re: [Wxdevide-devs] wxDevIDE announcement and workgroup

[Tony R. <re...@al...>]

Sure. Go ahead and commit any changes you think are necessary. I haven't
been playing with that branch for a while now.

I've started updating the packman2extended source code. Today, I just added
some Doxygen comments for the source code.

I think the major things missing from it are:

(1) doesn't handle the uncompressed devpackage files
(2) doesn't use the SQLite datatbase to keep track of devpak info
(3) doesn't allow for pre/post-processing scripts
(4) doesn't have a silent/automatic mode

Hopefully, I'll get to those 4 in the next few weeks. If anyone would like
to work with me, I could sure use the help. It's pure C++/wxWidgets code and
should make for a good stepping stone to getting psyched up for wxDevIDE.

-Tony



> I'd say go ahead. I found the problem with the images and changed the form
> accordingly (now using your "Use Original Format" although we should change
> this to ensure XPM generation and use).
>
> What might be an idea is to examine the code to Code::Blocks and CodeLite
> to see how they have set up the compilation etc.
>
> Anyway, I hope that we can make some headway soon.
>
> Best
> Mal
>

Re: [Wxdevide-devs] wxDevIDE announcement and workgroup

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

On Wed, Sep 16, 2009 at 8:04 PM, Tony Reina <re...@al...> wrote:

> All,
>
> It's been a few weeks now since the wxDev-C++ 7.0 release. Should we start
> to think about putting an announcement together now for wxDevIDE?
>
> I've been updating the Wiki pages for wxDevIDE. Also, I think we have
> Sof.T's source code in SVN, but it doesn't compile (missing a few of the XPM
> graphic files for the buttons). Perhaps we should start work on the skeleton
> source code for the IDE and the API?
>
> -Tony
>
>
I'd say go ahead. I found the problem with the images and changed the form
accordingly (now using your "Use Original Format" although we should change
this to ensure XPM generation and use).

What might be an idea is to examine the code to Code::Blocks and CodeLite to
see how they have set up the compilation etc.

Anyway, I hope that we can make some headway soon.

Best
Mal

[Wxdevide-devs] wxDevIDE announcement and workgroup

[Tony R. <re...@al...>]

All,

It's been a few weeks now since the wxDev-C++ 7.0 release. Should we start
to think about putting an announcement together now for wxDevIDE?

I've been updating the Wiki pages for wxDevIDE. Also, I think we have
Sof.T's source code in SVN, but it doesn't compile (missing a few of the XPM
graphic files for the buttons). Perhaps we should start work on the skeleton
source code for the IDE and the API?

-Tony

[Wxdevide-devs] Wiki page up

[Tony R. <re...@al...>]

I've started committing the wiki pages for the project. There's a bit of a
learning curve for trac wiki, but it's not too bad.

http://sourceforge.net/apps/trac/wxdevide/wiki

We should be able to all commit changes to the wiki at this point. Let me
know if you have trouble.

-Tony

Re: [Wxdevide-devs] trac editor plugin page

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

Just to clear up my position towards ReactOS: I still think this is the OSS project that I have the most interest in...

But, I'm a little rusty in C++, I figured there's no way for me to be productive in ReactOS until I have read enough documentation on that project, and also be proficient in C++ again. Meanwhile, wxDevIDE could be a good excercise for this goal.


--- El mié 19-ago-09, Nuklear Zelph <nuk...@gm...> escribió:

> De: Nuklear Zelph <nuk...@gm...>
> Asunto: [Wxdevide-devs] trac editor plugin page
> A: wxd...@li...
> Fecha: miércoles, 19 agosto, 2009, 10:06 pm
> http://sourceforge.net/apps/trac/wxdevide/wiki/EditorApi
> 
> I put up a starter page for the editor plugin. while i was
> at it i took a look at my developer page. i suggested last
> year that we each put one up to at least have a place to
> post what systems we are running and what projects we are
> working on. (at least the subprojects of wxDevIDE) not
> manditory, but it can help keep things straight and we will
> know who is best suited to test on one platform or other.
> obviously we all are a part of the whole project, but if we
> had the sub-projects we are kindof in charge of it can help
> users know who is best suited for talking to about a certain
> part of the project. other projects that are not part of
> wxDevIDE don't matter too much, but i figured i'd
> put mine up since they are loosly related anyway.
> 
> 
> i think it would be good to add some links to these pages
> to make it easier for an outsider to look through it all.
> right now everything is standalone. just a suggestion, the
> main page can have a link to the plugin api, developers
> pages if they want to put one up and whatever else there may
> be like documentation. then someone could follow links to
> where they want to go or use the index if they know what
> they are looking for, but that is hard to do if you
> don't know what is going on. 
> 
> 
> i don't know who all has looked at trac yet, the main
> page image is not showing up, i don't know where to find
> it so i'll let tony take care of it. he put that one up
> if i recall correctly. 
> 
> i forgot to remark about your comment earlier Esteban, i
> certainly want you to help with the plugin system, i have
> yet to make a very simple one work, i could not hope to make
> the one we are talking about work. if you are thinking of my
> comment about you maybe going to ReactOS, i was just trying
> to say that i would not hold anything against you or
> whatever. this is all hobby stuff and if we don't like
> our hobby we find a new one.
> 
> 
> Nuklear
> 
> 
> -----Adjunto en línea a continuación-----
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal
> Reports 2008 30-Day 
> trial. Simplify your report design, integration and
> deployment - and focus on 
> what you do best, core application coding. Discover what's
> new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> -----Adjunto en línea a continuación-----
> 
> _______________________________________________
> Wxdevide-devs mailing list
> Wxd...@li...
> https://lists.sourceforge.net/lists/listinfo/wxdevide-devs
> 


      ____________________________________________________________________________________
¡Obtén la mejor experiencia en la web!
Descarga gratis el nuevo Internet Explorer 8. 
http://downloads.yahoo.com/ieak8/?l=e1

[Wxdevide-devs] trac editor plugin page

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

http://sourceforge.net/apps/trac/wxdevide/wiki/EditorApi

I put up a starter page for the editor plugin. while i was at it i took a
look at my developer page. i suggested last year that we each put one up to
at least have a place to post what systems we are running and what projects
we are working on. (at least the subprojects of wxDevIDE) not manditory, but
it can help keep things straight and we will know who is best suited to test
on one platform or other. obviously we all are a part of the whole project,
but if we had the sub-projects we are kindof in charge of it can help users
know who is best suited for talking to about a certain part of the project.
other projects that are not part of wxDevIDE don't matter too much, but i
figured i'd put mine up since they are loosly related anyway.

i think it would be good to add some links to these pages to make it easier
for an outsider to look through it all. right now everything is standalone.
just a suggestion, the main page can have a link to the plugin api,
developers pages if they want to put one up and whatever else there may be
like documentation. then someone could follow links to where they want to go
or use the index if they know what they are looking for, but that is hard to
do if you don't know what is going on.

i don't know who all has looked at trac yet, the main page image is not
showing up, i don't know where to find it so i'll let tony take care of it.
he put that one up if i recall correctly.

i forgot to remark about your comment earlier Esteban, i certainly want you
to help with the plugin system, i have yet to make a very simple one work, i
could not hope to make the one we are talking about work. if you are
thinking of my comment about you maybe going to ReactOS, i was just trying
to say that i would not hold anything against you or whatever. this is all
hobby stuff and if we don't like our hobby we find a new one.

Nuklear

Re: [Wxdevide-devs] editor plugin and dialog

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

i was trying to figure out how the graphical representation would work. i
always figured that we would use the plugins and inheritance like you
already described. there is more than just the editor in that dialog. but
the parts that will be mostly affected by different editors are in the
general tab. maybe the editor should just give the dialog the contents of
that panel?

i agree about the designer. i think that we should have a light duty
executable just to deploy the designer as a standalone too. basically it
just needs to have the applicable parts of the plugin manager and load the
designer plugin and editor plugin and whatnot. probably won't need the
autocompletion, since it is just a rad. then everyone can use the designer
and not have to take dev with it. i like the xml idea, i think we need to
look at the design of other frameworks a little to know how to set it up if
we want to have the option of supporting others, but it will cater to
wxWidgets of course. there are a few problems i ran into with the internal
design, but they can be fixed in the c++ version. i'd have to look at the
xrc code to remember what they where though.

Nuklear





On Wed, Aug 19, 2009 at 11:38 AM, Tony Reina <tb...@gm...> wrote:

> Let's also not forget that it's the visual designer that will make or break
> the project. Without a good one, we will just be another Code::Blocks or
> ScITE. The visual RAD is "where the money is" so to speak.
>
> -Tony
>
>
>
> On Wed, Aug 19, 2009 at 8:08 AM, Esteban Aguilar B. <nab...@ya...>wrote:
>
>> I think you have most of the right concepts, but you are missing the best
>> way (in my opinion) of modeling objects that share functionality, especially
>> in the case of plugins: using inheritance and method overriding.
>>
>>
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Wxdevide-devs mailing list
> Wxd...@li...
> https://lists.sourceforge.net/lists/listinfo/wxdevide-devs
>
>

Re: [Wxdevide-devs] editor plugin and dialog

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

Let's also not forget that it's the visual designer that will make or break
the project. Without a good one, we will just be another Code::Blocks or
ScITE. The visual RAD is "where the money is" so to speak.

-Tony


On Wed, Aug 19, 2009 at 8:08 AM, Esteban Aguilar B. <nab...@ya...>wrote:

> I think you have most of the right concepts, but you are missing the best
> way (in my opinion) of modeling objects that share functionality, especially
> in the case of plugins: using inheritance and method overriding.
>
>

Re: [Wxdevide-devs] editor plugin and dialog

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

I think you have most of the right concepts, but you are missing the best way (in my opinion) of modeling objects that share functionality, especially in the case of plugins: using inheritance and method overriding. 

First you think of the MCD, all the common structures and methods required in the base class of the Editor (as you describe); then you define an abstract class with all these methods, from which the base Editor and all subsequent editors inherit. Then you add this class (and all other extendable classes of the IDE) to a package and deploy it as the wxDevIDE SDK.

Now, lets say you want to create an Editor that is specific to work with PHP code... you grab the SDK, inherit a class from Base Editor class, override the methods that you care about (let's say, the syntax highlighting method to make it PHP specific). So, the editor is not just a GUI static component to which you duck tape panels to add functionality... it is a polymorphic structure that can be actually expanded and specialized from the point of view of the code.

Of course, the IDE needs a plugin controller that knows about all the abstract classes, and instantiates them at run time at the appropriate places, and deals with the messaging, etc. So the IDE (through the plugin controller) only cares about an abstract editor… all editors are special cases, that happen to share most of their code with the base Editor (or none at all, if someone wants to define a completely new editor from the abstract class).

Remember that I have offered to work on this part of the code (the plugin controller) if you don't mind, I think I have some experience here that may come handy for the project. Of course, this part requires good communication and coordination with the rest of the code components (it's kind of a central point of the IDE), so it would be good to have good communication among us... that is, if you really want me to help here ;)



--- El mar 18-ago-09, Nuklear Zelph <nuk...@gm...> escribió:

> De: Nuklear Zelph <nuk...@gm...>
> Asunto: [Wxdevide-devs] editor plugin and dialog
> A: wxd...@li...
> Fecha: martes, 18 agosto, 2009, 9:43 pm
> i had an idea last night about the editor
> dialog. i keep thinking about it because that is mostly in
> my domain, so i will most likely be the one doing most of
> the work on it. (editor plugin i mean) if the editor dialog
> is built into the ide and make generic/realistic enough for
> most any decent editor solution, then all the extra editor
> specific stuff can be put in a different gui element. either
> a dialog that is brought up via a menu item added to the
> edit menu, or a notebook page that is appended to the editor
> dialog notebook. which solution should be dependant on
> developers preference and or the actual implementation. a
> few options can easily go into a notebook page, a more
> complicated thing or multiple panels should be in its own
> dialog. 
> 
> 
> then we determine what options should go in what of three
> categories:
> core
> gray (or optional)
> extended
> 
> extended is simply what is not in the other two.
> core is expected from any plugin anyone wants to add.
> syntax highlighting for example.
> 
> gray is an optional functionality, like line numbers and
> code folding.
> i think that cursor past eol, eof needs to go into extended
> if the editor supports it. to my knowledge, scintilla
> doesn't support it at all. 
> 
> 
> then dealing with the users settings, either:
> 
> *a structure with the core and gray settings is passed to
> the editor plugin when the user changes them so that the
> editor plugin can just deal with all of the settings
> itself.
> 
> 
> *or the same thing, but the ide deals with the settings,
> but this looks like a little worse solution because it will
> take more plugin bandwidth.
> 
> *or the settings are stored separately. 
> 
> 
> as an unrelated bit, my xp went to heck on me a couple
> weeks ago and some one stole my installer cd. so i had to
> find xs's xp1 on the Internet again to make a new one.
> what a chore. and finish up with my backup/housekeeping
> stuff. finally done, very glad its over. 
> 
> 
> just before i had that issue, i was working on XSTC, and i
> finally fixed an elusive bug in the configuration system. it
> kept crashing when it should not have been called at all.
> turns out i put the variable initializer below the config
> setup call in the constructor, all fixed yay! now i can get
> back to working on the next release of XSTC like i should
> have been doing this whole time. 
> 
> 
> i am also going to work on the editor plugin/dialog issue
> in a test program. i'll create a mock plugin system to
> develop the api and do some brainstorming. when the plugin
> documentation takes more form i will keep the mock up
> updated so the api is usable in the ide. that way the
> current editor stuff can be sorted out later when a good,
> ready to use editor is already built. it will make things
> easier to keep track of. and keep my editor api updated on
> the wiki.
> 
> 
> do i have any major errors in thinking about this or is it
> a good idea? opinions?
> 
> Nuklear
> 
> 
> -----Adjunto en línea a continuación-----
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal
> Reports 2008 30-Day 
> trial. Simplify your report design, integration and
> deployment - and focus on 
> what you do best, core application coding. Discover what's
> new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> -----Adjunto en línea a continuación-----
> 
> _______________________________________________
> Wxdevide-devs mailing list
> Wxd...@li...
> https://lists.sourceforge.net/lists/listinfo/wxdevide-devs
> 

__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis! 
Regístrate ya - http://correo.espanol.yahoo.com/ 

Re: [Wxdevide-devs] editor plugin and dialog

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

>
>
> *or the settings are stored separately.
>
>
I like this idea the best. In particular, I would suggest an XML format
since we can pass the entire option set as one XML object and just ignore
whatever options aren't supported by a particular editor. In fact, the XML
tree could have 3 primary nodes: core, grey, and extended. Plus, the can be
saved in an easy-to-read format.

-Tony

[Wxdevide-devs] editor plugin and dialog

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

i had an idea last night about the editor dialog. i keep thinking about it
because that is mostly in my domain, so i will most likely be the one doing
most of the work on it. (editor plugin i mean) if the editor dialog is built
into the ide and make generic/realistic enough for most any decent editor
solution, then all the extra editor specific stuff can be put in a different
gui element. either a dialog that is brought up via a menu item added to the
edit menu, or a notebook page that is appended to the editor dialog
notebook. which solution should be dependant on developers preference and or
the actual implementation. a few options can easily go into a notebook page,
a more complicated thing or multiple panels should be in its own dialog.

then we determine what options should go in what of three categories:
core
gray (or optional)
extended

extended is simply what is not in the other two.
core is expected from any plugin anyone wants to add. syntax highlighting
for example.
gray is an optional functionality, like line numbers and code folding.
i think that cursor past eol, eof needs to go into extended if the editor
supports it. to my knowledge, scintilla doesn't support it at all.

then dealing with the users settings, either:

*a structure with the core and gray settings is passed to the editor plugin
when the user changes them so that the editor plugin can just deal with all
of the settings itself.

*or the same thing, but the ide deals with the settings, but this looks like
a little worse solution because it will take more plugin bandwidth.

*or the settings are stored separately.


as an unrelated bit, my xp went to heck on me a couple weeks ago and some
one stole my installer cd. so i had to find xs's xp1 on the Internet again
to make a new one. what a chore. and finish up with my backup/housekeeping
stuff. finally done, very glad its over.

just before i had that issue, i was working on XSTC, and i finally fixed an
elusive bug in the configuration system. it kept crashing when it should not
have been called at all. turns out i put the variable initializer below the
config setup call in the constructor, all fixed yay! now i can get back to
working on the next release of XSTC like i should have been doing this whole
time.

i am also going to work on the editor plugin/dialog issue in a test program.
i'll create a mock plugin system to develop the api and do some
brainstorming. when the plugin documentation takes more form i will keep the
mock up updated so the api is usable in the ide. that way the current editor
stuff can be sorted out later when a good, ready to use editor is already
built. it will make things easier to keep track of. and keep my editor api
updated on the wiki.

do i have any major errors in thinking about this or is it a good idea?
opinions?

Nuklear

[Wxdevide-devs] wiki transfer

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

the wiki transfer is now complete. i don't remember exactly what was on it
before, it is now on the trac system. the old wiki url will redirect to the
trac space now. take a look at your pages and make sure that they still
work. i figured that if we found that we needed the extended functionality
later it would just be better to start on it rather than media wiki. if we
don't, we just don't use the features.

Nuklear

Re: [Wxdevide-devs] wiki move

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

I saw that. Yes, we definitely would like the wiki for formulating our
developer docs.

-Tony


On Wed, Jul 29, 2009 at 6:32 PM, Nuklear Zelph <nuk...@gm...>wrote:

> hey, sf.net said that they will be removing the wikispace. i dunno if
> anyone else got the notice. has anyone put in a support request? i have no
> idea how to use the new applications, but i can put in a request. do we need
> attachments other than just images? its either mediawiki or trac.
>
> Nuklear
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Wxdevide-devs mailing list
> Wxd...@li...
> https://lists.sourceforge.net/lists/listinfo/wxdevide-devs
>
>

[Wxdevide-devs] wiki move

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

hey, sf.net said that they will be removing the wikispace. i dunno if anyone
else got the notice. has anyone put in a support request? i have no idea how
to use the new applications, but i can put in a request. do we need
attachments other than just images? its either mediawiki or trac.

Nuklear

Re: [Wxdevide-devs] discussing wxDevIDE publicly

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

just curious, has anyone heard form kinming lately?

On Sun, Jul 26, 2009 at 2:14 PM, Nuklear Zelph <nuk...@gm...>wrote:

> i feel the same about keeping the look as close as possible, i suggested a
> "template" dialog just because not all editors are the same. i don't know if
> the rtf version would ever be a full blown and supported one or if i'd give
> it coloring options, but i could. i just mostly want to give that plugin a
> good test. scintilla does not suport cursor past end of like like synedit
> does. it would be a waist to NOT support code folding, so that's where i am
> comming from. and why i suggested a "sub dialog" for the other editor
> behavior. it would not encroach on the dev dialogs and all the stnedit like
> stuff can be plugged into the main dialog.
>
> Nuklear
>
> On Sun, Jul 26, 2009 at 11:32 AM, Tony Reina <tb...@gm...> wrote:
>
>>
>>
>>> At this point I think I would like to contribute in this area of the
>>> project, if you guys agree.
>>>
>>>
>>>
>> Yes, definitely do. At this point, our goal should be working on the
>> developers documentation/design (again). It looks like SF now has a Wiki
>> setup for the wxDevIDE project (http://wxdevide.wiki.sourceforge.net/).
>> Perhaps Nuklear can move the existing docs to that Wiki so that we'll have a
>> central spot to brainstorm and refine our goals.
>>
>> -Tony
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Wxdevide-devs mailing list
>> Wxd...@li...
>> https://lists.sourceforge.net/lists/listinfo/wxdevide-devs
>>
>>
>

Re: [Wxdevide-devs] discussing wxDevIDE publicly

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

i feel the same about keeping the look as close as possible, i suggested a
"template" dialog just because not all editors are the same. i don't know if
the rtf version would ever be a full blown and supported one or if i'd give
it coloring options, but i could. i just mostly want to give that plugin a
good test. scintilla does not suport cursor past end of like like synedit
does. it would be a waist to NOT support code folding, so that's where i am
comming from. and why i suggested a "sub dialog" for the other editor
behavior. it would not encroach on the dev dialogs and all the stnedit like
stuff can be plugged into the main dialog.

Nuklear

On Sun, Jul 26, 2009 at 11:32 AM, Tony Reina <tb...@gm...> wrote:

>
>
>> At this point I think I would like to contribute in this area of the
>> project, if you guys agree.
>>
>>
>>
> Yes, definitely do. At this point, our goal should be working on the
> developers documentation/design (again). It looks like SF now has a Wiki
> setup for the wxDevIDE project (http://wxdevide.wiki.sourceforge.net/).
> Perhaps Nuklear can move the existing docs to that Wiki so that we'll have a
> central spot to brainstorm and refine our goals.
>
> -Tony
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Wxdevide-devs mailing list
> Wxd...@li...
> https://lists.sourceforge.net/lists/listinfo/wxdevide-devs
>
>

Re: [Wxdevide-devs] discussing wxDevIDE publicly

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

>
> At this point I think I would like to contribute in this area of the
> project, if you guys agree.
>
>
>
Yes, definitely do. At this point, our goal should be working on the
developers documentation/design (again). It looks like SF now has a Wiki
setup for the wxDevIDE project (http://wxdevide.wiki.sourceforge.net/).
Perhaps Nuklear can move the existing docs to that Wiki so that we'll have a
central spot to brainstorm and refine our goals.

-Tony

Re: [Wxdevide-devs] discussing wxDevIDE publicly

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

On Sun, Jul 26, 2009 at 7:15 PM, Esteban Aguilar B. <nab...@ya...>wrote:

>
> > I have always said that we need to keep the
> > "LOOK AND FEEL" of wxDevC++. How we implement it
> > (e.g. Tstringlist/wxArrayString) is, for ME, unimportant. As
> > long as it looks like wxDevC++ and feels like wxDevC++
> > (especially the designer) then I'm a happy
> > chappie.
>
> I agree with Mal. In fact, I think the point of wxDevIDE is the chance of
> getting rid of tons of things wxDevCpp does wrong. Sure, the current code
> may be helpful in understanding several things, like how the compiler, the
> debugger or the designer stuff works, etc. but in my opinion it would be a
> big mistake just taking the code and try to translate it to C++.


Designing the IDE should be reasonably simple, since we are just replicating
a lot of dialogs in the first place. And I do agree that attempting to
merely translate the Delphi to C++ is fraught with problems.


>
>
> You don't want to try to deal with the huge ass TMainForm mess again. In
> fact, a good desing separates the GUI stuff from the business domain
> objects; in that regard, the TMainForm implementation is a fundamentally
> flawed desing.
>
> I can give several other examples of things wxDevCpp does wrong: for one,
> event-driven sections of code are very difficult to understand. I've had
> lots of pain looking for the right place in code that gets executed after
> some obvious action in the GUI; there are several places that use things
> like the repaint event of some component to check on the state of some other
> component to trigger some action. Again, a good design requires the control
> of the flow of actions to be condenced in some well defined objects in which
> these tasks are clearly identified.


I too found it difficult to fathom when some of the code was actually being
run.


>
>
>
>
> I've written a proposal on how the plugins support could be modeled.
>
> http://wxdevide.wiki.sourceforge.net/wxDevIDE+API?f=print
>
> I know it is a little confusing, but my idea could be summarized in
> observing which parts of the IDE are good candidates for plugin replacement,
> and implement all the comunication between them and the cotroller objects
> throwgh interfaces (c++ abstract classes).
>
> At this point I think I would like to contribute in this area of the
> project, if you guys agree.
>
>
I say go ahead. Any hard and fast documentation is good when we are all so
spread out as we are.

Best regards
Mal

Re: [Wxdevide-devs] discussing wxDevIDE publicly

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

> defenatly need to talk about wxDevIDE. i took a look at the
> code and then i felt overwhelmed and kinda quit. some of the
> delphi stuff is duplicated over an already exsisting C++
> solution. Tstringlist could be replaced with wxArrayString,
> unless there is a viable reason we need to keep the other
> one or that the wx version is too unstable. i have not seen
> that it is. 
> 
> I have always said that we need to keep the
> "LOOK AND FEEL" of wxDevC++. How we implement it
> (e.g. Tstringlist/wxArrayString) is, for ME, unimportant. As
> long as it looks like wxDevC++ and feels like wxDevC++
> (especially the designer) then I'm a happy
> chappie.

I agree with Mal. In fact, I think the point of wxDevIDE is the chance of getting rid of tons of things wxDevCpp does wrong. Sure, the current code may be helpful in understanding several things, like how the compiler, the debugger or the designer stuff works, etc. but in my opinion it would be a big mistake just taking the code and try to translate it to C++. 

You don't want to try to deal with the huge ass TMainForm mess again. In fact, a good desing separates the GUI stuff from the business domain objects; in that regard, the TMainForm implementation is a fundamentally flawed desing.

I can give several other examples of things wxDevCpp does wrong: for one, event-driven sections of code are very difficult to understand. I've had lots of pain looking for the right place in code that gets executed after some obvious action in the GUI; there are several places that use things like the repaint event of some component to check on the state of some other component to trigger some action. Again, a good design requires the control of the flow of actions to be condenced in some well defined objects in which these tasks are clearly identified.


> also in
> keeping the interface the same it will mean configuration
> dialogs too. most generally for the compiler this is easy
> from what i have seen, but the editor is a different matter.
> we can't make it a clone, but that is not the point. we
> have an issue with the [editor dialog]&[editor] combo.
> do we just MAKE the dialog as Devish as possible and pass it
> to the ide or do we make a template class and have the
> plugin fill it out. obviously if we don't use a plugin
> for this there is no problem, but, planning for the future
> makes things a lot easier.
> 
> If I understand you correctly, I believe that
> the editor "plugin", should contain the editor
> itself as well as the config dialog. This should be as wxDev
> as possible, removing what is not supported (I don't
> think graying out is an option here since graying out
> suggests that some action results in UNgraying), and adding
> any options that are not supported by synedit (Code Folding
> for example). This info could/should be in its own config
> file, separate from the general stuff for the IDE.

I've written a proposal on how the plugins support could be modeled.

http://wxdevide.wiki.sourceforge.net/wxDevIDE+API?f=print

I know it is a little confusing, but my idea could be summarized in observing which parts of the IDE are good candidates for plugin replacement, and implement all the comunication between them and the cotroller objects throwgh interfaces (c++ abstract classes).

At this point I think I would like to contribute in this area of the project, if you guys agree.


      ____________________________________________________________________________________
¡Obtén la mejor experiencia en la web!
Descarga gratis el nuevo Internet Explorer 8. 
http://downloads.yahoo.com/ieak8/?l=e1

Re: [Wxdevide-devs] discussing wxDevIDE publicly

[Tony R. <re...@al...>]

>
>
> As mentioned in my reply to Tony, if it is a simple change to paths etc.
> then we could offer a "Running under Wine" option which could implement the
> changes in Linux/Wine for the user.
>
>

To expand on what is needed for the makefile:

Nuklear and I found that wxWidgets under Linux has a nice program called
"wx-config" which "asks" the runtime wxWidgets libraries what flags they
were built with (e.g. monolithic, exceptions, debug/releae, unicode/ansi,
etc.). So instead of a makefile that looks like this:

CPP = g++.exe
CC = gcc.exe
LIBS      = -L"C:/Program Files/Dev-Cpp/Lib" -lwxmsw28_stc -mwindows
-lwxmsw28 -lwxmsw28_gl -lwxtiff -lwxjpeg -lwxpng -lwxzlib -lwxregex
-lwxexpat -lkernel32 -luser32 -lgdi32 -lcomdlg32 -lwinspool -lwinmm
-lshell32 -lcomctl32 -lole32 -loleaut32 -luuid -lrpcrt4 -ladvapi32 -lwsock32
-lodbc32 -lopengl32
INCS      = -I"C:/Program Files/Dev-Cpp/Include"

we'd have something that look like this:

CPP = `wx-config --cc`
CC = `wx-config --cpp`
LIBS =`wx-config --wxlibs`
CXXINCS =`wx-config --cxxflags`

As you can see, it's an abstraction of the current makefile that just calls
"wx-config" at build time. What's brilliant is that we'd be able to use
anyone's wxWidgets build (and not have to keep producing our own devpaks).
wx-config would just query the unknown lib about what flags it needs.

There's an open-source project (http://wxconfig.googlepages.com/) that has
ported wx-config to windows. However, we still have the problem that
backticks `` aren't handled in Windows makefiles. This would require a work
around where we would call wx-config directly from wxDev-C++ at makefile
generation time to get the correct compiler types/flags/etc.

I'd like to see the wx-config approach used in wxDevIDE, but hesitate to add
it to wxDev-C++. Instead it might be good just to give the end-user the
information in a Wiki (tutorial) and just let them manually modify the
makefile. However, currently I don't have a Linux box to test things on or
write more specific instructions. Nuklear and I last tested on 6.10.2
probably more than a year or two ago. No idea how the new plugin version
will work.

-Tony

Re: [Wxdevide-devs] discussing wxDevIDE publicly

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

On Sun, Jul 26, 2009 at 6:41 AM, Tony Reina <re...@al...> wrote:


>
>>  In my opinion, we should generally try to stay with built in wxWidgets
> types as much as possible.


Here Here.


> One of the disadvantages of wxDev-C++ is that we rely on several 3rd party
> packages. That makes it hard to set the development environment up and
> discourages potential new developers (well that and the Delphi language).


Plus almost anything we need to setup the IDE is easily added to the source
tree, since most of the 3rd party components are on wxCode, wxForum or other
supported sites.


> Plus, we know that wxWidgets is cross-platform and well maintained (yes,
> I'm looking at you SynEdit).


And is continually evolving.


Best Regards

Mal

Re: [Wxdevide-devs] discussing wxDevIDE publicly

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

On Sun, Jul 26, 2009 at 4:59 AM, Nuklear Zelph <nuk...@gm...>wrote:

> I think that waiting a little is a good idea. we should decide what we will
> say when we make the announcement. i think that we should let people know
> that wxDev-C++ will be the current "stable use" version for a while. maybe
> we could report our findings of using wine?


As mentioned in my reply to Tony, if it is a simple change to paths etc.
then we could offer a "Running under Wine" option which could implement the
changes in Linux/Wine for the user.


> yes we defenatly need to talk about wxDevIDE. i took a look at the code and
> then i felt overwhelmed and kinda quit. some of the delphi stuff is
> duplicated over an already exsisting C++ solution. Tstringlist could be
> replaced with wxArrayString, unless there is a viable reason we need to keep
> the other one or that the wx version is too unstable. i have not seen that
> it is.


I have always said that we need to keep the "LOOK AND FEEL" of wxDevC++. How
we implement it (e.g. Tstringlist/wxArrayString) is, for ME, unimportant. As
long as it looks like wxDevC++ and feels like wxDevC++ (especially the
designer) then I'm a happy chappie.

also in keeping the interface the same it will mean configuration dialogs
> too. most generally for the compiler this is easy from what i have seen, but
> the editor is a different matter. we can't make it a clone, but that is not
> the point. we have an issue with the [editor dialog]&[editor] combo. do we
> just MAKE the dialog as Devish as possible and pass it to the ide or do we
> make a template class and have the plugin fill it out. obviously if we don't
> use a plugin for this there is no problem, but, planning for the future
> makes things a lot easier.


If I understand you correctly, I believe that the editor "plugin", should
contain the editor itself as well as the config dialog. This should be as
wxDev as possible, removing what is not supported (I don't think graying out
is an option here since graying out suggests that some action results in
UNgraying), and adding any options that are not supported by synedit (Code
Folding for example). This info could/should be in its own config file,
separate from the general stuff for the IDE.

 If you examine the SVN repository, there should be a branch for the
Scintilla version that I was working on, You might get a better idea of what
I am discussing there (although that was a while ago, and I am not sure of
the state of the code, but the editor dialog should be there showing what I
thought then to be the best option.)


I am strongly leaning toword building two editor plugins side by side. one
> uses XSTC, the other wxRTF. initially the calltips and autocompletion will
> be stubs in the rtf version. it will not color syntax either. but the
> scintilla lexing code can be reused and the coloring code can be revamped.
> the calltips and autocompletion will need to be created, but that won't be a
> big issue right away. my biggest concern is keeping the plugin flexible to
> manage with another editor realistically. we can put an extended
> configuration dialog in the editor dialog for more control over the specific
> behavior of a plugin editor. (like home() and homext()) the rtf editor will
> not have the second version. also the menu bar can set some of the
> functionality. basically the rtf version will become a light plugin and the
> XSTC one a fully featured one. This is primarily an effort to keep the
> editor plugin api realistic and reasonable.


If you think that this is a sensible thing to do (obviously with an eye on
possible future editor components this is a sensible thing to do) then go
for it.




> what xml library are we going to use? i have used TinyXML in the past
> because it is small and light weight, but expat is distributed with
> wxWidgets. i also know of exceres and libxml. there is a wx wrapper for both
> tinyxml and libxml on wxcode. i looked at expat and felt that it was straing
> to use but i wasn't too prepared to directly handle a c library at the time.
> i know there is a wx xml api too, i don't know anything about it, does it
> use expat? in wx2.6 the docs had an unstable api warning, is it still the
> same? we need to remember the form designer in this too. is it going to be
> xml driven, do we need to use xpath?


I'll defer to Tony's expertise on this.

does anyone know whats up with wxWidgets adding wxScintilla to their trunk?
> i know the name makes a lot more sense than wxStyledTextCtrl, but they are
> the same thing. i use wxScintilla and keep it up-to-date with the current
> verison of scintilla. i hack the inclusions and recursive prevention header
> macros so it will build in dev and CB and add the newest languages to
> wxscintilla.h. there was a little hack i needed to put into wxScintilla.cpp
> or Scintillawx.cpp to make the newer scintilla's work. unless someone else
> is keeping up with it too, which i haven't seen any evidence for, i have the
> most current version. so i use it instead of STC for everything. (and keep
> XSTC up with it.) which do we use? it looks like either will work with
> wxWidgets soon.


If it is possible to allow the wxDevIde to build and run using any of the
possible editors then I'll be happy. I don't know the reasoning behind the
whole scintilla/stc implementation, but I'll leave that for the core
developers.

Those are my conserns right now. more debate has yet to come of course. i am
> still doing some housekeeping. i got fedora11 installed and fought with mp3
> playback. i finally figured out how to make it work in xine. i am back to
> working on a text editor i started last time i was using linux because i
> need something more powerful than gedit and it is the perfect excuse to
> drive XSTC. dual booting is the best way i know of to keep the cross
> platform code working as it should on both platforms and keeping the system
> related case sensitivity in linux compliant.


I don't dual boot, but use VirtualBox and run it under Vista. This has the
benefit of not needing to reboot to check differences between Linux/Windows.

also what about the website. i can built it if someone can design the
> interface, but i am no graphic designer. do we copy the wxDev-C++ one or? i
> now have a server on bluehost, we could put it on there, is that a good
> idea? it gives us full control over the backend, i have a linux server with
> apache 2.2 and php5 running. we could use ruby-on-rails, ruby gems,
> mod_python over just php and there is an sql database too. is any of that
> stuff necessary for what we need to put on the website? the current one has
> been neglected for a year, so its probably time to think about it. i have
> not needed to work with a database, so that would be a learning experience
> for me, but that is partly why i put up a website of my own.


I'll leave those decisions to those less "graphically challenged" than
myself.


> That covers what's on my mind, hope i didn't bore anyone too much.


Not bored, but we do need to focus now on the future. If anyone else has any
thoughts/concerns then they should be voiced, as we should be starting to
move forward on this reasonably soon.

Best Regards

Mal

Re: [Wxdevide-devs] discussing wxDevIDE publicly

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

On Sun, Jul 26, 2009 at 2:14 AM, Tony Reina <tb...@gm...> wrote:

> Yes, I've had the exact same thoughts.
>
>  I suppose my preference would be to wait until a week or so after we
> release 7.0 to make any announcement about wxDevIDE. My thought is that we
> shouldn't steal 7.0's thunder. Also, I'm not sure if people will be hesitant
> to upgrade if they think there is a forthcoming new IDE.



I agree, although I don't think we should announce it so soon. We could of
course simply wait until we have something to show before we announce
anything. Another option would be to simply state that this will be the last
release with anything added, and that we wxDevC++ is going into bugfix mode
for a while. So that we could in effect release a newer version of wxDevC++
as we develop wxDevIde. If anyone has any ideas for improving wxDevC++ then
they could implement them within wxDevC++ but also "must" consider how that
improvement could be carried over into wxDevIde.



> In reality, when Nuklear and I tested wxDev-C++ with Wine under Linux, it
> performed quite well. The biggest problem we had was that the makefiles
> weren't properly written (since the libs and compilers were different on
> Linux). However, it is possible to manually alter the makefile and get the
> projects to compile and run just fine. So Wine is a viable (albeit not
> ideal) alternative for the present time.


So would it be a simple change to allow a checkbox somewhere which the user
could select that says "Running under WINE". If selected then the makefile
generation could be changed to reflect the new paths (assuming that this is
a simple change to the makefiles generation)? This would allow the current
program to function as a true "stopgap" cross platform IDE. I am not sure
what happens on Mac, but I assume someone will tell us. It might even be
necessary to change the checkbox to a combobox offering choices of
Windows/Wine/WineOnMac.  Just a thought.

Best Regards
Mal

Re: [Wxdevide-devs] discussing wxDevIDE publicly

[Tony R. <re...@al...>]

>
> what xml library are we going to use? i have used TinyXML in the past
> because it is small and light weight, but expat is distributed with
> wxWidgets. i also know of exceres and libxml. there is a wx wrapper for both
> tinyxml and libxml on wxcode. i looked at expat and felt that it was straing
> to use but i wasn't too prepared to directly handle a c library at the time.
> i know there is a wx xml api too, i don't know anything about it, does it
> use expat? in wx2.6 the docs had an unstable api warning, is it still the
> same? we need to remember the form designer in this too. is it going to be
> xml driven, do we need to use xpath?
>
>
I tried tinyXML initially with wx2xml, but found it offered no advantages
over the built in XML parser in wxWidgets (
http://docs.wxwidgets.org/stable/wx_wxxmldocument.html#wxxmldocument). So my
vote is to use the built-in one.

 In my opinion, we should generally try to stay with built in wxWidgets
types as much as possible. One of the disadvantages of wxDev-C++ is that we
rely on several 3rd party packages. That makes it hard to set the
development environment up and discourages potential new developers (well
that and the Delphi language). Plus, we know that wxWidgets is
cross-platform and well maintained (yes, I'm looking at you SynEdit).

-Tony

Re: [Wxdevide-devs] discussing wxDevIDE publicly

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

I think that waiting a little is a good idea. we should decide what we will
say when we make the announcement. i think that we should let people know
that wxDev-C++ will be the current "stable use" version for a while. maybe
we could report our findings of using wine?

yes we defenatly need to talk about wxDevIDE. i took a look at the code and
then i felt overwhelmed and kinda quit. some of the delphi stuff is
duplicated over an already exsisting C++ solution. Tstringlist could be
replaced with wxArrayString, unless there is a viable reason we need to keep
the other one or that the wx version is too unstable. i have not seen that
it is.

also in keeping the interface the same it will mean configuration dialogs
too. most generally for the compiler this is easy from what i have seen, but
the editor is a different matter. we can't make it a clone, but that is not
the point. we have an issue with the [editor dialog]&[editor] combo. do we
just MAKE the dialog as Devish as possible and pass it to the ide or do we
make a template class and have the plugin fill it out. obviously if we don't
use a plugin for this there is no problem, but, planning for the future
makes things a lot easier.

I am strongly leaning toword building two editor plugins side by side. one
uses XSTC, the other wxRTF. initially the calltips and autocompletion will
be stubs in the rtf version. it will not color syntax either. but the
scintilla lexing code can be reused and the coloring code can be revamped.
the calltips and autocompletion will need to be created, but that won't be a
big issue right away. my biggest concern is keeping the plugin flexible to
manage with another editor realistically. we can put an extended
configuration dialog in the editor dialog for more control over the specific
behavior of a plugin editor. (like home() and homext()) the rtf editor will
not have the second version. also the menu bar can set some of the
functionality. basically the rtf version will become a light plugin and the
XSTC one a fully featured one. This is primarily an effort to keep the
editor plugin api realistic and reasonable.

what xml library are we going to use? i have used TinyXML in the past
because it is small and light weight, but expat is distributed with
wxWidgets. i also know of exceres and libxml. there is a wx wrapper for both
tinyxml and libxml on wxcode. i looked at expat and felt that it was straing
to use but i wasn't too prepared to directly handle a c library at the time.
i know there is a wx xml api too, i don't know anything about it, does it
use expat? in wx2.6 the docs had an unstable api warning, is it still the
same? we need to remember the form designer in this too. is it going to be
xml driven, do we need to use xpath?

does anyone know whats up with wxWidgets adding wxScintilla to their trunk?
i know the name makes a lot more sense than wxStyledTextCtrl, but they are
the same thing. i use wxScintilla and keep it up-to-date with the current
verison of scintilla. i hack the inclusions and recursive prevention header
macros so it will build in dev and CB and add the newest languages to
wxscintilla.h. there was a little hack i needed to put into wxScintilla.cpp
or Scintillawx.cpp to make the newer scintilla's work. unless someone else
is keeping up with it too, which i haven't seen any evidence for, i have the
most current version. so i use it instead of STC for everything. (and keep
XSTC up with it.) which do we use? it looks like either will work with
wxWidgets soon.

Those are my conserns right now. more debate has yet to come of course. i am
still doing some housekeeping. i got fedora11 installed and fought with mp3
playback. i finally figured out how to make it work in xine. i am back to
working on a text editor i started last time i was using linux because i
need something more powerful than gedit and it is the perfect excuse to
drive XSTC. dual booting is the best way i know of to keep the cross
platform code working as it should on both platforms and keeping the system
related case sensitivity in linux compliant.

also what about the website. i can built it if someone can design the
interface, but i am no graphic designer. do we copy the wxDev-C++ one or? i
now have a server on bluehost, we could put it on there, is that a good
idea? it gives us full control over the backend, i have a linux server with
apache 2.2 and php5 running. we could use ruby-on-rails, ruby gems,
mod_python over just php and there is an sql database too. is any of that
stuff necessary for what we need to put on the website? the current one has
been neglected for a year, so its probably time to think about it. i have
not needed to work with a database, so that would be a learning experience
for me, but that is partly why i put up a website of my own.

That covers what's on my mind, hope i didn't bore anyone too much.

Nuklear

On Sat, Jul 25, 2009 at 6:14 PM, Tony Reina <tb...@gm...> wrote:

> Yes, I've had the exact same thoughts.
>
>  I suppose my preference would be to wait until a week or so after we
> release 7.0 to make any announcement about wxDevIDE. My thought is that we
> shouldn't steal 7.0's thunder. Also, I'm not sure if people will be hesitant
> to upgrade if they think there is a forthcoming new IDE.
>
> In reality, when Nuklear and I tested wxDev-C++ with Wine under Linux, it
> performed quite well. The biggest problem we had was that the makefiles
> weren't properly written (since the libs and compilers were different on
> Linux). However, it is possible to manually alter the makefile and get the
> projects to compile and run just fine. So Wine is a viable (albeit not
> ideal) alternative for the present time.
>
> Finally, since Nuklear is the lead on wxDevIDE, I wanted to give him a
> chance to do the formal announcement (unless he wishes to defer to one of
> us).
>
> Nuklear? Any thoughts?
>
> -Tony
>
>
>
> On Sat, Jul 25, 2009 at 4:56 PM, Esteban Aguilar B. <nab...@ya...>wrote:
>
>> I said that I may not be that much involved with wxDevIDE, but I'm not
>> sure of this yet; as wxDeCpp 7 is getting closer, I'm actually feeling a
>> little more entusiastic about wxDevIDE again.
>>
>> That said, would it be a good idea to start discussing this project more
>> publicly? As always, people ask (
>> http://wxforum.shadonet.com/viewtopic.php?t=24962)  about wxDevCpp not
>> being multiplatform and its kind of bad not giving any answers to them.
>>
>> Or, would it be better to wait for the final 7.0 relase of wxDevCpp to
>> make the announcement?
>>
>>
>>
>>  ____________________________________________________________________________________
>> ¡Obtén la mejor experiencia en la web!
>> Descarga gratis el nuevo Internet Explorer 8.
>> http://downloads.yahoo.com/ieak8/?l=e1
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Wxdevide-devs mailing list
>> Wxd...@li...
>> https://lists.sourceforge.net/lists/listinfo/wxdevide-devs
>>
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Wxdevide-devs mailing list
> Wxd...@li...
> https://lists.sourceforge.net/lists/listinfo/wxdevide-devs
>
>