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