wxdevide-devs — Developer discussion for the project.

Re: [Wxdevide-devs] Status?

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

Can you provide the url?

-Tony


On Sun, Oct 18, 2009 at 3:46 PM, Nuklear Zelph <nuk...@gm...>wrote:

> i have the current api on the editorapi page in trac now.
>
> Nuklear
>
>
> On Sat, Oct 17, 2009 at 9:40 PM, Tony Reina <re...@al...> wrote:
>
>> Awesome. Can't wait to start playing with the code.
>>
>> -Tony
>>
>>
>>
>> On Sat, Oct 17, 2009 at 9:20 PM, Nuklear Zelph <nuk...@gm...>wrote:
>>
>>> got my old machine up and running with a new xp installation, helps to
>>> find the installer disk. will need to ask an expert to program me a new bios
>>> for the new mainboard, too bad.
>>>
>>> i'll get back on the api stuff now that i have the theoretical issues
>>> worked out with the notebook. it should not be hard to work on the remaining
>>> api's and i can get a first draft on the wiki and fine tune things later.
>>>
>>> Nuklear
>>>
>>> On Sat, Oct 17, 2009 at 9:56 AM, M Nealon <m.n...@wa...> wrote:
>>>
>>>>
>>>>
>>>> On Sat, Oct 17, 2009 at 5:49 PM, Tony Reina <re...@al...> wrote:
>>>>
>>>>>
>>>>>> Not too sure where I can best help, since you are all far better
>>>>>> programmers than I, but I think I might concentrate on getting the
>>>>>> internationalization and themes working (once Nuklear has the scintilla bit
>>>>>> done) since this is probably the least code intensive part (obviously we
>>>>>> would want to allow the user to reuse his own theme if possible).
>>>>>>
>>>>>>
>>>>>>
>>>>> With your knowledge of devpaks, I could definitely use you for the
>>>>> packman2extended and packmaker2extended development. The programs are
>>>>> already written and working, but we could use a fresh set of eyes to work
>>>>> through potential bugs and usability issues. If you have time, please think
>>>>> of it.
>>>>>
>>>>
>>>>
>>>> Will look into it as time allows.
>>>>
>>>> Regards
>>>> Mal
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
>>>> is the only developer event you need to attend this year. Jumpstart your
>>>> developing skills, take BlackBerry mobile applications to market and
>>>> stay
>>>> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
>>>> http://p.sf.net/sfu/devconference
>>>> _______________________________________________
>>>> Wxdevide-devs mailing list
>>>> Wxd...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/wxdevide-devs
>>>>
>>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
>>> is the only developer event you need to attend this year. Jumpstart your
>>> developing skills, take BlackBerry mobile applications to market and stay
>>> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
>>> http://p.sf.net/sfu/devconference
>>> _______________________________________________
>>> Wxdevide-devs mailing list
>>> Wxd...@li...
>>> https://lists.sourceforge.net/lists/listinfo/wxdevide-devs
>>>
>>>
>>
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Wxdevide-devs mailing list
> Wxd...@li...
> https://lists.sourceforge.net/lists/listinfo/wxdevide-devs
>
>

Re: [Wxdevide-devs] Status?

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

i have the current api on the editorapi page in trac now.

Nuklear

On Sat, Oct 17, 2009 at 9:40 PM, Tony Reina <re...@al...> wrote:

> Awesome. Can't wait to start playing with the code.
>
> -Tony
>
>
>
> On Sat, Oct 17, 2009 at 9:20 PM, Nuklear Zelph <nuk...@gm...>wrote:
>
>> got my old machine up and running with a new xp installation, helps to
>> find the installer disk. will need to ask an expert to program me a new bios
>> for the new mainboard, too bad.
>>
>> i'll get back on the api stuff now that i have the theoretical issues
>> worked out with the notebook. it should not be hard to work on the remaining
>> api's and i can get a first draft on the wiki and fine tune things later.
>>
>> Nuklear
>>
>> On Sat, Oct 17, 2009 at 9:56 AM, M Nealon <m.n...@wa...> wrote:
>>
>>>
>>>
>>> On Sat, Oct 17, 2009 at 5:49 PM, Tony Reina <re...@al...> wrote:
>>>
>>>>
>>>>> Not too sure where I can best help, since you are all far better
>>>>> programmers than I, but I think I might concentrate on getting the
>>>>> internationalization and themes working (once Nuklear has the scintilla bit
>>>>> done) since this is probably the least code intensive part (obviously we
>>>>> would want to allow the user to reuse his own theme if possible).
>>>>>
>>>>>
>>>>>
>>>> With your knowledge of devpaks, I could definitely use you for the
>>>> packman2extended and packmaker2extended development. The programs are
>>>> already written and working, but we could use a fresh set of eyes to work
>>>> through potential bugs and usability issues. If you have time, please think
>>>> of it.
>>>>
>>>
>>>
>>> Will look into it as time allows.
>>>
>>> Regards
>>> Mal
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
>>> is the only developer event you need to attend this year. Jumpstart your
>>> developing skills, take BlackBerry mobile applications to market and stay
>>> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
>>> http://p.sf.net/sfu/devconference
>>> _______________________________________________
>>> Wxdevide-devs mailing list
>>> Wxd...@li...
>>> https://lists.sourceforge.net/lists/listinfo/wxdevide-devs
>>>
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
>> is the only developer event you need to attend this year. Jumpstart your
>> developing skills, take BlackBerry mobile applications to market and stay
>> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
>> http://p.sf.net/sfu/devconference
>> _______________________________________________
>> Wxdevide-devs mailing list
>> Wxd...@li...
>> https://lists.sourceforge.net/lists/listinfo/wxdevide-devs
>>
>>
>

Re: [Wxdevide-devs] Status?

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

Awesome. Can't wait to start playing with the code.

-Tony


On Sat, Oct 17, 2009 at 9:20 PM, Nuklear Zelph <nuk...@gm...>wrote:

> got my old machine up and running with a new xp installation, helps to find
> the installer disk. will need to ask an expert to program me a new bios for
> the new mainboard, too bad.
>
> i'll get back on the api stuff now that i have the theoretical issues
> worked out with the notebook. it should not be hard to work on the remaining
> api's and i can get a first draft on the wiki and fine tune things later.
>
> Nuklear
>
> On Sat, Oct 17, 2009 at 9:56 AM, M Nealon <m.n...@wa...> wrote:
>
>>
>>
>> On Sat, Oct 17, 2009 at 5:49 PM, Tony Reina <re...@al...> wrote:
>>
>>>
>>>> Not too sure where I can best help, since you are all far better
>>>> programmers than I, but I think I might concentrate on getting the
>>>> internationalization and themes working (once Nuklear has the scintilla bit
>>>> done) since this is probably the least code intensive part (obviously we
>>>> would want to allow the user to reuse his own theme if possible).
>>>>
>>>>
>>>>
>>> With your knowledge of devpaks, I could definitely use you for the
>>> packman2extended and packmaker2extended development. The programs are
>>> already written and working, but we could use a fresh set of eyes to work
>>> through potential bugs and usability issues. If you have time, please think
>>> of it.
>>>
>>
>>
>> Will look into it as time allows.
>>
>> Regards
>> Mal
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
>> is the only developer event you need to attend this year. Jumpstart your
>> developing skills, take BlackBerry mobile applications to market and stay
>> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
>> http://p.sf.net/sfu/devconference
>> _______________________________________________
>> Wxdevide-devs mailing list
>> Wxd...@li...
>> https://lists.sourceforge.net/lists/listinfo/wxdevide-devs
>>
>>
>
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Wxdevide-devs mailing list
> Wxd...@li...
> https://lists.sourceforge.net/lists/listinfo/wxdevide-devs
>
>

[Wxdevide-devs] Status?

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

got my old machine up and running with a new xp installation, helps to find
the installer disk. will need to ask an expert to program me a new bios for
the new mainboard, too bad.

i'll get back on the api stuff now that i have the theoretical issues worked
out with the notebook. it should not be hard to work on the remaining api's
and i can get a first draft on the wiki and fine tune things later.

Nuklear

On Sat, Oct 17, 2009 at 9:56 AM, M Nealon <m.n...@wa...> wrote:

>
>
> On Sat, Oct 17, 2009 at 5:49 PM, Tony Reina <re...@al...> wrote:
>
>>
>>> Not too sure where I can best help, since you are all far better
>>> programmers than I, but I think I might concentrate on getting the
>>> internationalization and themes working (once Nuklear has the scintilla bit
>>> done) since this is probably the least code intensive part (obviously we
>>> would want to allow the user to reuse his own theme if possible).
>>>
>>>
>>>
>> With your knowledge of devpaks, I could definitely use you for the
>> packman2extended and packmaker2extended development. The programs are
>> already written and working, but we could use a fresh set of eyes to work
>> through potential bugs and usability issues. If you have time, please think
>> of it.
>>
>
>
> Will look into it as time allows.
>
> Regards
> Mal
>
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Wxdevide-devs mailing list
> Wxd...@li...
> https://lists.sourceforge.net/lists/listinfo/wxdevide-devs
>
>

Re: [Wxdevide-devs] Status?

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

On Sat, Oct 17, 2009 at 5:49 PM, Tony Reina <re...@al...> wrote:

>
>> Not too sure where I can best help, since you are all far better
>> programmers than I, but I think I might concentrate on getting the
>> internationalization and themes working (once Nuklear has the scintilla bit
>> done) since this is probably the least code intensive part (obviously we
>> would want to allow the user to reuse his own theme if possible).
>>
>>
>>
> With your knowledge of devpaks, I could definitely use you for the
> packman2extended and packmaker2extended development. The programs are
> already written and working, but we could use a fresh set of eyes to work
> through potential bugs and usability issues. If you have time, please think
> of it.
>


Will look into it as time allows.

Regards
Mal

Re: [Wxdevide-devs] Status?

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

>
>
> Not too sure where I can best help, since you are all far better
> programmers than I, but I think I might concentrate on getting the
> internationalization and themes working (once Nuklear has the scintilla bit
> done) since this is probably the least code intensive part (obviously we
> would want to allow the user to reuse his own theme if possible).
>
>
>
With your knowledge of devpaks, I could definitely use you for the
packman2extended and packmaker2extended development. The programs are
already written and working, but we could use a fresh set of eyes to work
through potential bugs and usability issues. If you have time, please think
of it.

-Tony

Re: [Wxdevide-devs] Status?

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

On Thu, Oct 15, 2009 at 10:15 PM, Tony Reina <re...@al...> wrote:

> I just wanted to check up on what everyone was doing. Is there any work on
> the API or the docs? I was hoping that by the end of the year we would have
> the basic API done and the initial core module.
>
> I've been getting closer to the end of the PackMan C++/wxWidgets port (
> packman2extended <https://sourceforge.net/projects/packman2/>). With the
> latest SVN, it should be able to handle all of the functionality of the
> current Delphi version of PackMan. I still have to add in the extended
> features like the pre- and post- batch file execution and the SQLite
> database. It probably would be useful to have some people test it out for
> bugs.
>
>
Unfortunately I haven't had any time to do anything. Not even on my own
projects.

Doubly unfortunate, for me in any case, is that my contract is ending
shortly and the company has had a few setbacks so it looks as though I won't
get a new contract.

This is of course good news for my projects, wxdevide and wxdevcpp included,
since it means that I might actually get around to doing the things I wanted
to do  or in any case am able to do on them too.

Not too sure where I can best help, since you are all far better programmers
than I, but I think I might concentrate on getting the internationalization
and themes working (once Nuklear has the scintilla bit done) since this is
probably the least code intensive part (obviously we would want to allow the
user to reuse his own theme if possible).

Best
Mal

Re: [Wxdevide-devs] Status?

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

i have been using a partially corrupted os for a few months because i was
too lazy to fix it and i had lost the installer disk. (so i was in the
middle of making a new one, sort of) so that has made some things harder to
do. i finally got so sick of it i am now working on reinstalling. i found
the mainboard i bought does not work, so i am trying to flash the bios and
hope that it was just corrupt, so i will hopefully find out by tomarrow if i
just lost 80 bucks or not.

i have most of the text editor related api done, i still have the automated
text manipulation api to look at (macros) and i just got a notebook class
working mostly. it defaults to creating new documents for the single XSTC
instance inside of it, but you can pass another window too. i fixed the
events in erans Notebook class from codelite 1 and made a wrapper for it to
deal with automatic switching the editor parent and stuff. needs some work,
but the basics work, so i can figure out how to make a good notebook api
that will work with both this style and the traditional style notebook
windowing approaches. i have not messed with the dialog issue any more and i
have yet to get around to the code completion.

hopefully by tomarrow night i will have a fresh new ssytem running that will
give me a stable dev to work with.

Nuklear

On Thu, Oct 15, 2009 at 4:15 PM, Tony Reina <re...@al...> wrote:

> I just wanted to check up on what everyone was doing. Is there any work on
> the API or the docs? I was hoping that by the end of the year we would have
> the basic API done and the initial core module.
>
> I've been getting closer to the end of the PackMan C++/wxWidgets port (
> packman2extended <https://sourceforge.net/projects/packman2/>). With the
> latest SVN, it should be able to handle all of the functionality of the
> current Delphi version of PackMan. I still have to add in the extended
> features like the pre- and post- batch file execution and the SQLite
> database. It probably would be useful to have some people test it out for
> bugs.
>
> -Tony
>
>
>
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Wxdevide-devs mailing list
> Wxd...@li...
> https://lists.sourceforge.net/lists/listinfo/wxdevide-devs
>
>

[Wxdevide-devs] Status?

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

I just wanted to check up on what everyone was doing. Is there any work on
the API or the docs? I was hoping that by the end of the year we would have
the basic API done and the initial core module.

I've been getting closer to the end of the PackMan C++/wxWidgets port (
packman2extended <https://sourceforge.net/projects/packman2/>). With the
latest SVN, it should be able to handle all of the functionality of the
current Delphi version of PackMan. I still have to add in the extended
features like the pre- and post- batch file execution and the SQLite
database. It probably would be useful to have some people test it out for
bugs.

-Tony

[Wxdevide-devs] announce

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

Announcing wxDevIDE, Dev-C++ in
C++<http://wxforum.shadonet.com/viewtopic.php?t=25679>

i posted the announement in the wxDev-C++ section, it seemed appropriate. I
don't know if there should be a reference in the other annoucement forum,
but if so someone else can take care of it. it will be interesting to see
the responses.

Nuklear

[Wxdevide-devs] announce

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

I've shared a document with you:

announce
https://docs.google.com/Doc?docid=0ASMCAO13qBr1ZGY2ZGdxZzhfMTZjYm5yNHhjMw&hl=en&invite=CIjJmKQG

It's not an attachment -- it's stored online at Google Docs. To open this  
document, just click the link above.

Here's my edit of the announcement.

-Tony

Re: [Wxdevide-devs] editor plugin

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

Actually I like the Notebook parent because I think it fits in with the
concept of a workspace or project space. We should make sure that the
notebook/workspace handler can accept editor objects and RAD designer
objects. So the handle to a notebook is the handle to all of the
files/objects for one user project.

-Tony


On Sun, Sep 27, 2009 at 3:36 PM, Nuklear Zelph <nuk...@gm...>wrote:

> this is a model i came up with today. supposing we decide to use the
> multi-document singe editor approach, we will want to have the notebook
> inside the editor plugin in order to keep trancparency for other editors. if
> we want it to be part of the main gui, then we should scrap the idea,
> because of the normal behavior of a notebook. as far as the notebook is
> conserned there is not much of a difference whether it is in the editor
> plugin or the gui. it has a small api for attaching and removing panels and
> that is not much of a big deal.
>
> with the one doc per editor approach will not be hindered either way we
> create it. the notebook will be in the same place one way or another, so it
> probably depends on what affects it might have on the plugin system
> bandwidth and such.
>
> i am working on the api's mentioned in the picture. the final decision of
> what needs to go where is a ways off right now, the api that any plugin
> would see is not going to change between the two approaches and niether will
> the base editor, but the resulting plugin can only do what it has been given
> resources for, so i am just wondering what we think is the best way to
> design this is.
>
> when i can log into sf.net i'll post the pic onto the editor api page.
>
> Nuklear
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Wxdevide-devs mailing list
> Wxd...@li...
> https://lists.sourceforge.net/lists/listinfo/wxdevide-devs
>
>

[Wxdevide-devs] wxDevIDE announcement

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


I started a project space on SourceForge.net a couple years ago called wxDevIDE. The purpose of the project was to port Dev-C++ from Delphi to C++, making it cross platform using the wxWidgets toolkit. I didn't get too far at the time because shortly after starting the project my extra time disappeared. A while later things changed again and last September I proposed to the wxDev-C++ team, I had been helping some in the past, that we all change over to the C++ project. We had talked about doing something like that in the past and Delphi6 was not getting any more popular. 

We decided to finish the new changes and release a new version of wxDev-C++ and then switch to wxDevIDE. One of the biggest changes was the separation of the form designer from the ide using the new plugin system. Should it be necessary later on this would also allow for updates in the form designer to keep up with wxWidgets while we where working on building the C++ version. Recently we released wxDev-C++ version 7, now we are getting started on wxDevIDE. There is still a lot of work to be done, a working version is quite a ways off, so those of you who use wxDev-C++ or Dev-C++ should continue to do so. 

The goals of the project are:
Porting Dev-C++ and the form designer to C++ and include the added functionalities that have been introduced into the wxDev-C++ version of the ide.
Some of these are a plugin system, dockable windows, multiple compiler support.
Improve on some of the original short comings of the original ide.
the new ide is going to be built very modular, the "frame" so-to-speak will be the plugin system. The GUI will be its own module, compiler, debugger, editor. Each module will work as independently as practical and the plugin system will be the means by which they communicate. 

We decided to make the editor a separate plugin, so that if there was a need to change in the future, it would not be a painful process. We will be using Scintilla (wxScintilla) as the editor component.

An improved code completion is one of the improvements being planned.

Other functionalities of the current ide can be put into plugins as well. The CVS version control interface built into the ide for example, project importing and formatted source exporting.

An improved version of the package manager has also been started. It will work with regular Dev type packages and some extensions are being worked on that will make it a little better. One of those is a database that keeps track of dependencies for each package. The current project is called "packman2extended".

Also, the current form designer is going to be ported as a plugin. A small front end app will be created to use the form designer as a stand alone later on, so other ide users can use it without the bloat of the whole ide if they are not going to be using it. The internals will be altered with the designer as well. Instead of needing to link in each new component, XML templates will be used. This way updating the components will be much easier and faster. It will be easier to support multiple versions of wxWidgets and other toolkits could be supported as well. The main advantage of using wxWidgets to create the form designer in this case is that it will be a true what-you-see-is-what-you-get form designer. The form designer is just as important a part of the project as the ide. Instead of the wxform (Delphi form code) file format, XML is going to be used. Hopefully something similar to XRC format so it can be imported into other XRC supporting form designers. Other information that XRC does not support will naturally need to be included to make it all work. 

All of us are currently marked as project admins on the project space to keep the development efforts flowing well. Everyone has a strong grasp of different aspects of the project and it makes sense to do that. I started the project and am kind of the primary admin. We welcome any help on the new project. Alpha testers, developers, whatever, if you want to help just email one of us or the mailing list and we can get you set up. Sof.t did some porting of the GUI and some of the other parts of Dev-C++. The code that he worked on has been committed to SVN on the wxDevIDE project space. We are using Trac to develop documentation and api's for the project. One goal is to keep strong documentation for the sources so that others can contribute more easily and future difficulties of not having good documentation does not catch up to the project. 

Although the code is going to be different and it is going to work differently inside. wxDevIDE is going to be as comfortable and farmiliar to a Dev-C++/wxDev-C++ user as possible. There are some things that wont be identical, like some of the editor options in the editor dialog because we are not using Synedit, but using it will be just about the same as the Delphi version. We are trying to make dev more free, not make a new, different ide.

Just a note to those who think that Code::Blocks is better, or [your ide here]. That is great for you, use it. Please do not bother us with complaints, we do not spam your developers, please give us the same courtesy.

Nuklear Zelph

Re: [Wxdevide-devs] scintilla multiple documents

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

sounds like a good idea. i just want to be sure what we want in it.

i think from previous conversations that this should sum up what we want to
say:

introduce wxDevIDE
its purpose:
port wxDevC++ to C++ using the wxWidgets toolkit, also making it cross
platform.
modernize the original ide by giving it a powerful and flexible plugin
system that will do the following as well as allow some others.
multiple compiler support
allow use of different editor components such as scintilla which is what
will be used in official development.
some of the graphical components can be accessed by certain plugins to add
other functionality to the ide like:
    project file conversion/importing
    a version control interface (moving devs current cvs parts to a plugn or
allow other types of version control)
    embedded form designer
    formatted source exporting
    any other plugins that need a graphical interface to use them

the current form designer in wxDevC++ is going to be ported as well and
revamped to use xml based templates so that it can produce different kinds
of output code. (such as win32) and new components do not need to be
compiled into the designer to be added.

mention the svn code currently in the project space.


as i recall that covers what we have discussed, if i missed something let me
know. i will write up an announcement and post it here for review before i
make it live.

Nuklear


On Sat, Sep 26, 2009 at 1:17 PM, Tony Reina <tb...@gm...> wrote:

> That sounds great. You may want to look at ScITE to get ideas of how they
> handle Scintilla. Do you plan on still using your wx abstraction layer to
> access Scintilla?
>
> Also, do you want to handle the wxDevIDE announcement on the wxForum? It's
> probably a good time to tell people what we've been up to. Might even
> generate some help from other developers.
>
> -Tony
>
>
> On Thu, Sep 24, 2009 at 9:25 PM, Nuklear Zelph <nuk...@gm...>wrote:
>
>> while i was looking through scintillas api and working on an editor plugin
>> api i ran across an interesting functionality that scintilla has. i have
>> seen it before, but not explored it any. so i decided to write a simple
>> manager class to handle the slight complexity of using it.
>>
>> scintilla is seperated in a few ways. there is a gui layer, the backend
>> and a document. having the document seperated form the rest of the editor
>> allows for that same document to be viewed and edited by multiple scintilla
>> instances at once. or simply to use one scintilla window to edit multiple
>> buffers at once.  it uses reference counting to know when to destroy a
>> document. scintilla gives you a void pointer to a document so you cannot
>> destroy it yourself.
>>
>> the usage of the manager class is simple, create an instance, passing your
>> scintilla window to it. then when you want to create, destroy or switch
>> documents you make a simple function call. all reference counting and
>> storage is handled for you. it does not handle multiple views, i don't think
>> i want to make it that big. i attached it along with a test program. its not
>> complete, i just figured it may be an option we could use with the ide, but
>> that may make the editor part more dependant that we want it to be.
>>
>> the document in scintilla is more than just text, or it would be as easy
>> as storing a string. lexers , markers, selected text, possibly more is
>> stored in the document, so they are all per document information. possibly
>> codepage and line ending and that sort of thing too. so using a multi-buffer
>> single window editor approach, this simplifies swapping. just an idea at
>> this early stage, we can still use the same basic idea with a different
>> editor, it would just require us to manage more of the information
>> ourselves, (or the editor plugin handles it anyway)
>>
>> Nuklear
>>
>>
>> ------------------------------------------------------------------------------
>> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
>> is the only developer event you need to attend this year. Jumpstart your
>> developing skills, take BlackBerry mobile applications to market and stay
>> ahead of the curve. Join us from November 9&#45;12, 2009. Register
>> now&#33;
>> http://p.sf.net/sfu/devconf
>> _______________________________________________
>> Wxdevide-devs mailing list
>> Wxd...@li...
>> https://lists.sourceforge.net/lists/listinfo/wxdevide-devs
>>
>>
>

Re: [Wxdevide-devs] scintilla multiple documents

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

That sounds great. You may want to look at ScITE to get ideas of how they
handle Scintilla. Do you plan on still using your wx abstraction layer to
access Scintilla?

Also, do you want to handle the wxDevIDE announcement on the wxForum? It's
probably a good time to tell people what we've been up to. Might even
generate some help from other developers.

-Tony


On Thu, Sep 24, 2009 at 9:25 PM, Nuklear Zelph <nuk...@gm...>wrote:

> while i was looking through scintillas api and working on an editor plugin
> api i ran across an interesting functionality that scintilla has. i have
> seen it before, but not explored it any. so i decided to write a simple
> manager class to handle the slight complexity of using it.
>
> scintilla is seperated in a few ways. there is a gui layer, the backend and
> a document. having the document seperated form the rest of the editor allows
> for that same document to be viewed and edited by multiple scintilla
> instances at once. or simply to use one scintilla window to edit multiple
> buffers at once.  it uses reference counting to know when to destroy a
> document. scintilla gives you a void pointer to a document so you cannot
> destroy it yourself.
>
> the usage of the manager class is simple, create an instance, passing your
> scintilla window to it. then when you want to create, destroy or switch
> documents you make a simple function call. all reference counting and
> storage is handled for you. it does not handle multiple views, i don't think
> i want to make it that big. i attached it along with a test program. its not
> complete, i just figured it may be an option we could use with the ide, but
> that may make the editor part more dependant that we want it to be.
>
> the document in scintilla is more than just text, or it would be as easy as
> storing a string. lexers , markers, selected text, possibly more is stored
> in the document, so they are all per document information. possibly codepage
> and line ending and that sort of thing too. so using a multi-buffer single
> window editor approach, this simplifies swapping. just an idea at this early
> stage, we can still use the same basic idea with a different editor, it
> would just require us to manage more of the information ourselves, (or the
> editor plugin handles it anyway)
>
> Nuklear
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Wxdevide-devs mailing list
> Wxd...@li...
> https://lists.sourceforge.net/lists/listinfo/wxdevide-devs
>
>

[Wxdevide-devs] scintilla multiple documents

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

while i was looking through scintillas api and working on an editor plugin
api i ran across an interesting functionality that scintilla has. i have
seen it before, but not explored it any. so i decided to write a simple
manager class to handle the slight complexity of using it.

scintilla is seperated in a few ways. there is a gui layer, the backend and
a document. having the document seperated form the rest of the editor allows
for that same document to be viewed and edited by multiple scintilla
instances at once. or simply to use one scintilla window to edit multiple
buffers at once.  it uses reference counting to know when to destroy a
document. scintilla gives you a void pointer to a document so you cannot
destroy it yourself.

the usage of the manager class is simple, create an instance, passing your
scintilla window to it. then when you want to create, destroy or switch
documents you make a simple function call. all reference counting and
storage is handled for you. it does not handle multiple views, i don't think
i want to make it that big. i attached it along with a test program. its not
complete, i just figured it may be an option we could use with the ide, but
that may make the editor part more dependant that we want it to be.

the document in scintilla is more than just text, or it would be as easy as
storing a string. lexers , markers, selected text, possibly more is stored
in the document, so they are all per document information. possibly codepage
and line ending and that sort of thing too. so using a multi-buffer single
window editor approach, this simplifies swapping. just an idea at this early
stage, we can still use the same basic idea with a different editor, it
would just require us to manage more of the information ourselves, (or the
editor plugin handles it anyway)

Nuklear

Re: [Wxdevide-devs] editor options dialog

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

Esteban has quite a lot of experience with coding APIs. He'd undoubtedly
have some useful tips.

-Tony


On Tue, Sep 22, 2009 at 11:49 AM, Nuklear Zelph <nuk...@gm...>wrote:

> ok, i just wanted to see if i was barking up the wrong tree before i put my
> time into creating something that had some big flaw that i couldn't see. i
> will work on the code some more so that i can present a more complete
> version that is actually clear. i'm still working out the api for the editor
> plugin. my first attemp at the mock plugin was a bust, so i am going to try
> just calling the api for the plugin alone and that will probably do the same
> thing i was trying to in the first place. when i have some more of the
> details worked out i'll put what i have on the wiki.
>
> Nuklear
>
>
>
>
> On Mon, Sep 21, 2009 at 10:45 PM, Tony Reina <tb...@gm...> wrote:
>
>>
>>
>>> i just got started on this, i am wondering what your opinions are of this
>>> approach. the idea is that one derrives from the OptsPanel class and creates
>>> their own panel. then it
>>> can handle all of the updating without any intervention, a closed ciruet
>>> module so-to-speak.
>>>
>>>
>> The closed-circuit idea is definitely the right track; we want each
>> "module" to be as independent as possible. Although, I must confess that I
>> really don't understand the rest of the proposal yet. I suppose I'll just
>> need to see it when it makes it into the code to tell whether I like it or
>> not.
>>
>> I've got the Wiki pages up and running. If you want to add these ideas to
>> the API or outline pages, it would probably help. I figure it's a good idea
>> to use the wiki to brainstorm our plans.
>>
>> -Tony
>>
>>
>>
>

Re: [Wxdevide-devs] editor options dialog

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

ok, i just wanted to see if i was barking up the wrong tree before i put my
time into creating something that had some big flaw that i couldn't see. i
will work on the code some more so that i can present a more complete
version that is actually clear. i'm still working out the api for the editor
plugin. my first attemp at the mock plugin was a bust, so i am going to try
just calling the api for the plugin alone and that will probably do the same
thing i was trying to in the first place. when i have some more of the
details worked out i'll put what i have on the wiki.

Nuklear



On Mon, Sep 21, 2009 at 10:45 PM, Tony Reina <tb...@gm...> wrote:

>
>
>> i just got started on this, i am wondering what your opinions are of this
>> approach. the idea is that one derrives from the OptsPanel class and creates
>> their own panel. then it
>> can handle all of the updating without any intervention, a closed ciruet
>> module so-to-speak.
>>
>>
> The closed-circuit idea is definitely the right track; we want each
> "module" to be as independent as possible. Although, I must confess that I
> really don't understand the rest of the proposal yet. I suppose I'll just
> need to see it when it makes it into the code to tell whether I like it or
> not.
>
> I've got the Wiki pages up and running. If you want to add these ideas to
> the API or outline pages, it would probably help. I figure it's a good idea
> to use the wiki to brainstorm our plans.
>
> -Tony
>
>
>

Re: [Wxdevide-devs] editor options dialog

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

>
> i just got started on this, i am wondering what your opinions are of this
> approach. the idea is that one derrives from the OptsPanel class and creates
> their own panel. then it
> can handle all of the updating without any intervention, a closed ciruet
> module so-to-speak.
>
>
The closed-circuit idea is definitely the right track; we want each "module"
to be as independent as possible. Although, I must confess that I really
don't understand the rest of the proposal yet. I suppose I'll just need to
see it when it makes it into the code to tell whether I like it or not.

I've got the Wiki pages up and running. If you want to add these ideas to
the API or outline pages, it would probably help. I figure it's a good idea
to use the wiki to brainstorm our plans.

-Tony

[Wxdevide-devs] editor options dialog

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

i have a solution to the dialog issue:

a special class for creating and handling a panel and the config settings
for each component is optionally passed to the editor options dialog.
(actually though a dialog data class like how wxWidgets does it.)
if the correct panel is there, it creates that one and lets it handle the
config entries and such, if not it creates a generic default one based on
what the editor plugin tells it about available "gray" options.

here is a start to the class that will handle the panel and config settings

#ifndef OPTSPANEL_H
#define OPTSPANEL_H

#include <wx/panel.h>
#include <wx/window.h>
#include <wx/sizer.h>
#include <wx/wx.h>

//this class is nonvisual. it creates a panel with items on it and
automatically, it is also hopefully flexible enough to use in more than just
the one dialog if neccesary
//updates settings in a config group to the users input of the panel
class OptsPanel
{
    public:
    OptsPanel(wxConfigBase* config = NULL, wxString grouphead);//does this
need an optional callback() too?
    virtual ~OptsPanel();
    wxPanel* Create(wxWindow* parent, wxSizer* sizer = NULL, int perportion
= 0, long flags = 0);//an optional sizer for the panel to be added into
    void SaveSettings();
    void Destroy();//do we need to do anything here

    private:
    wxConfigBase* conf;//this way the config database can be whatever we
need
    wxWindow* myparent;//we need this for the panel, which will in turn be
the parent for each component
    wxSizer* mysizer;//optionally add this panel to a sizer, or should we
let the dialog do that for us?
    int myperportion;
    long myflags;
    //the arraystring is going tosave all of the user changeable components,
this way each can be searched for to get states and update the config entry
for it.
    wxArrayString controls; //this is for the user interactive controls
    //name:_:type:
    //Use AntiAliasing:_:checkbox
    //config entry name:Use_AntiAliasing=true/false
    void GetConfSettings();//once all of the components are created, they
need to be updated to show the current config state
    wxCheckBox* CreateCheckBox(wxString* name, int id);
    wxRadioBox* CreateRadioBox(wxArrayString* arrstr, int id);//a specific
control creation function to set up this component
    void NameToConf(wxString string);//changes the caption to the config
entry, also used as the name
};

/*
using this class:
derive from it and override the create function. inside it create a panel
and add it
to the sizer if it is given. then use the createcomponent() functions to put
items on
the panel. They create a list of the items that the user can interact with.
this list
is used to find the components and ask their state. the names of the
components are
used to both create a config entry and create the label of the component if
applicable.

once you have created your panel in Create(), call GetConfSettings() to
update each
component to display the current saved settings for each. then return the
panel.
SaveSettings() is automatically called before destroying each OptsPanel
instance.
wxWidgets will destroy the visual components.

*/

#endif //OPTSPANEL_H




right now i am just figuring on the general, display and classbrowser/code
completion panels. do we need to worry about the other two there? we can
probably create a structure to hold all of the color settings that can be
passed back to the editor plugin rather than make one of these panels. but
if it needs to be more flexible, especialy for other languages, then it
should probably have a panel too. i was just figuring on it making a
config-based theme and all of the file formats are then handled by XSTC
automatically.

currently the editor dialog takes the parent, id and dialogdata:

EditorDlg(wxWindow *parent, wxWindowID id = 1,  EditorOptsData* data =
NULL);

i just got started on this, i am wondering what your opinions are of this
approach. the idea is that one derrives from the OptsPanel class and creates
their own panel. then it
can handle all of the updating without any intervention, a closed ciruet
module so-to-speak.

i could write it with a creation api and avoid the need to derive from it,
but this gives a developer more power. all the parent/handler needs to do is
call create, savesettings when it is closing (and possibly destroy if we
need to deal with the actual components, but i think wxWidgets can handle it
fine.) everything else is dealt with.

the generic version would call the editors "gray" availible functions and
create a default panel from that data, like graying out the not-availible
check boxes. this may be useable in other places too. an autocreate version
might just take a string or arraystring and parse it for creation info, but
at the sacrifice of the developer choosing its layout.

Nuklear

Re: [Wxdevide-devs] wxDevIDE announcement and workgroup

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

ok, i'll make the api support it.

Nuklear

On Thu, Sep 17, 2009 at 4:25 PM, Tony Reina <re...@al...> wrote:

> Oh, ok. That makes sense.
>
> Something like that could be extended to allow for "undo"/"redo" of the
> designer. We could keep a running tab of all of the designer events in a
> list of use it to "undo" changes to components.
>
> -Tony
>
>
> On Thu, Sep 17, 2009 at 11:49 AM, Nuklear Zelph <nuk...@gm...>wrote:
>
>> no, i mean automatic text manipulation macros. like recording user actions
>> till told to stop and then playing those back, that kind of macros.
>>
>> Nuklear
>>
>>
>> On Wed, Sep 16, 2009 at 10:43 PM, Tony Reina <re...@al...> wrote:
>>
>>>
>>>
>>> On Wed, Sep 16, 2009 at 7:17 PM, Nuklear Zelph <nuk...@gm...>wrote:
>>>
>>>> i started the editor plugin test/api devel project yesterday. i started
>>>> on the editor api. i am wondering if we want to support some kind of macros?
>>>>
>>>>
>>> What do you mean when you say "macros"? I was thinking that we should
>>> have some sort of ability for the user to define variable names that can be
>>> used in place of directories. For example, instead of hardcoding a directory
>>> like "c:\program files\dev-cpp\bin" we could just allow for "<app>\bin".
>>> Don't know if that's what you had in mind.
>>>
>>> -Tony
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
>> is the only developer event you need to attend this year. Jumpstart your
>> developing skills, take BlackBerry mobile applications to market and stay
>> ahead of the curve. Join us from November 9&#45;12, 2009. Register
>> now&#33;
>> http://p.sf.net/sfu/devconf
>> _______________________________________________
>> Wxdevide-devs mailing list
>> Wxd...@li...
>> https://lists.sourceforge.net/lists/listinfo/wxdevide-devs
>>
>>
>

Re: [Wxdevide-devs] wxDevIDE announcement and workgroup

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

Oh, ok. That makes sense.

Something like that could be extended to allow for "undo"/"redo" of the
designer. We could keep a running tab of all of the designer events in a
list of use it to "undo" changes to components.

-Tony


On Thu, Sep 17, 2009 at 11:49 AM, Nuklear Zelph <nuk...@gm...>wrote:

> no, i mean automatic text manipulation macros. like recording user actions
> till told to stop and then playing those back, that kind of macros.
>
> Nuklear
>
>
> On Wed, Sep 16, 2009 at 10:43 PM, Tony Reina <re...@al...> wrote:
>
>>
>>
>> On Wed, Sep 16, 2009 at 7:17 PM, Nuklear Zelph <nuk...@gm...>wrote:
>>
>>> i started the editor plugin test/api devel project yesterday. i started
>>> on the editor api. i am wondering if we want to support some kind of macros?
>>>
>>>
>> What do you mean when you say "macros"? I was thinking that we should have
>> some sort of ability for the user to define variable names that can be used
>> in place of directories. For example, instead of hardcoding a directory like
>> "c:\program files\dev-cpp\bin" we could just allow for "<app>\bin". Don't
>> know if that's what you had in mind.
>>
>> -Tony
>>
>>
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Wxdevide-devs mailing list
> Wxd...@li...
> https://lists.sourceforge.net/lists/listinfo/wxdevide-devs
>
>

Re: [Wxdevide-devs] wxDevIDE announcement and workgroup

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

no, i mean automatic text manipulation macros. like recording user actions
till told to stop and then playing those back, that kind of macros.

Nuklear

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

>
>
> On Wed, Sep 16, 2009 at 7:17 PM, Nuklear Zelph <nuk...@gm...>wrote:
>
>> i started the editor plugin test/api devel project yesterday. i started on
>> the editor api. i am wondering if we want to support some kind of macros?
>>
>>
> What do you mean when you say "macros"? I was thinking that we should have
> some sort of ability for the user to define variable names that can be used
> in place of directories. For example, instead of hardcoding a directory like
> "c:\program files\dev-cpp\bin" we could just allow for "<app>\bin". Don't
> know if that's what you had in mind.
>
> -Tony
>
>

[Wxdevide-devs] Fwd: wxDevIDE announcement and workgroup

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

---------- Forwarded message ----------
From: Nuklear Zelph <nuk...@gm...>
Date: Wed, Sep 16, 2009 at 8:17 PM
Subject: Re: wxDevIDE announcement and workgroup
To: Tony Reina <re...@al...>


i started the editor plugin test/api devel project yesterday. i started on
the editor api. i am wondering if we want to support some kind of macros?

i have just released a new version os XSTC. i think it finally is good
enough for a big app, i fixed some config system issues. i tried the
wxXMLConfig class i found but it didn't work at all.

i am hoping to figure out a good solution to the edior options dialog. i
think that the completion module should have an api for completion popups,
so i am going to figure out how to make that work. also i am working of
categorizing the functionalities.

Nuklear


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

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

[Wxdevide-devs] Elevating permission in Vista

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

All,

I found a neat trick.

I realized that the new PackMan executable needed to request elevation to
admin status in order to install or remove devpaks. It's not a trivial
process since you need to create a manifest file and link it to the
executable.

However, MS include a legacy set of keywords that will trigger the request
for UAC elevation automatically. Just go to Project->Project
Options->Version Info and in the file description include the keywords
"update" or "install". When Vista detects these words in the version, it
will spawn the elevation request before the program is executed. Voila! No
extra steps to do.

-Tony