wxdevide-devs

[Wxdevide-devs] discussing wxDevIDE publicly

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

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

Re: [Wxdevide-devs] discussing wxDevIDE publicly

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

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
>

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

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

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

[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

[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