wxdevide-devs — Developer discussion for the project.

[Wxdevide-devs] editor plugin

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

my text editor project is now on sf.net
http://sourceforge.net/projects/nztexteditor/
Its inteded to show off XSTC and MultiBook (notebook component)
its also going to help me actaully get the editor/notebook module bult
finally.

the editor plugin based on Scintilla is going to use MultiBook and XSTC. I
am hoping to completely drop wxScintilla/STC support using ExtScintilla.
its a wrapper that takes a pointer to your instance of scintilla and lets
you talk to it via the wxScintilla api. that api will cover the editor api
for wxDevIDE.the purpose of building this api is simply put, STC and
wxScintilla are woefully slow at updating the Scintilla version. I havent
gotten to wxDevIDE yet to see if i can get it running in fedora the text
editor has taken my time. im also helping remodel a trailer house so i have
a bit less time than i would, although the cold wheather is making that
project slow as well. i am going to write a minimalist plugin based on
wxRichText to help stress test the basic plugin api. it will not be fancy,
but it will get the job done. its possible that could grow into a usable
alternative plugin that doesn't require any nonwxwidgets components but i
have no such plans at the moment.

the editor plugin will make use of ExtScintilla, MultiBook and XSTC. I have
to build the first two before it can be a reality, im 1 third of the way
there anyway. MultiBook is half written, the manager stuff is pretty much
done but i had some strange issues with the drawing code. I mostly kept
drawing code seperate from manager code and recently i did some research
into gtk3. and i got qt to build arora 11 on windows, when i realised it
would take very little extra effort to make MultiBook work on those
toolkits too. since i have not run across a notebook that will do any of
the things im trying to do except for the themeing, why not share it. im
probably going to do a gtk2 and 3 version but i have to finish the wx
version so the platform interface is finished.

I have almost got my editor codebase arranged how i want so i can commit to
svn and then i will take a look at the ide. im trying to keep up with my
progress on the blog. i didnt realize how nice those where untill now. im
hoping that the text editor project wont look dead like the ide has so far.

When i get to the ide ill write up a webpage to replace the current website
and possibly build a windows and linux binary for the file release system.
they wont do much but it will make my webpage more convincing.

Nuklear

[Wxdevide-devs] Updated SVN

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

wxDevIDE guys,

I updated the source code in SVN so that it should now load into wxDev-C++
7.4 and build properly. I've also posted a pre-alpha executable to the file
release system on SourceForge. The program is currently only a shell--
Sof.T was converting the Delphi source code function by function into
C++/wxWidgets and it still needs a lot more code to be converted. However,
it's a really good start and might get some others interested in working
with us.

-Tony

[Wxdevide-devs] New devpak server

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

Sourceforge would like us to move the devpak server to their new file
release system (FRS). The advantage is that it has a list of mirrors that
the url re-directs to for faster access and a more distributed download
system worldwide.

I've gone ahead and copied the devpak files to
http://sourceforge.net/projects/wxdsgn/files/devpaks/<https://sourceforge.net/projects/wxdsgn/files/devpaks/>

I've been able to update the wxDev-C++ webinstaller to use the new url
(which was a little tricky since it re-directs to a random mirror). From my
tests, if the mirrors.cfg file is updated, then wxDev-C++'s autoupdater
works just fine with the new url repository.

I'll keep the old devpak directory up for a month or so just in case things
go wrong. Please make sure that all devpak updates go to the new FRS
directory.

Thanks.
-Tony

Re: [Wxdevide-devs] Idea for IDE

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

Yes, that would be a nice idea for all output windows.

-Tony


On Tue, Sep 20, 2011 at 10:07 AM, M Nealon <mal...@gm...> wrote:

> Hi All,
>
> I am currently busy looking into wxAui, and came across something which I
> miss in VS2010. Search in the output windows.
>
> Say I have changed a variable, moving it from public: to private:
>
> When the library is compiled, I obviously get lots of errors, but I would
> like to search the results and find ONLY those related to the relocated
> variable.
>
> Is this something you would like to see implemented?
>
> regards
> Mal
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Wxdevide-devs mailing list
> Wxd...@li...
> https://lists.sourceforge.net/lists/listinfo/wxdevide-devs
>
>

[Wxdevide-devs] Idea for IDE

[M N. <mal...@gm...>]

Hi All,

I am currently busy looking into wxAui, and came across something which I
miss in VS2010. Search in the output windows.

Say I have changed a variable, moving it from public: to private:

When the library is compiled, I obviously get lots of errors, but I would
like to search the results and find ONLY those related to the relocated
variable.

Is this something you would like to see implemented?

regards
Mal

[Wxdevide-devs] wxDevIDE

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

last time we used this list i think we had all gone different ways, id like
to know if any work has been done on this project by anyone since then. I am
going to get back on it, but it will be somewhat slow probably, just don't
want to duplicate effort.

i plan on looking for a gtk solution to resizable control unless one has
been found
building a shell for the editor module
probably forking the codebase to strip out the delphi-ish code for a cleaner
start point on the gui and possibly look at AUI-ing the main form
i might draft a project file and workspace file format. also i think aside
from compiler profiles the project needs build targets, an annoying lack in
dev.
also a current project file needs a way to add a compiler profile, i don't
know if that's done in wxdev but it crossed my mind.

i guess that might be base for a file release for version .001 unless we
have a different versioning method in mind. possibly the same as dev then
0.0.0.1 ? or 0.0.0.1A (for alpha)
i think the second release might have a semi-working project file parser
that would load the project files from the tree ctrl when clicked on. the
editor options dialog should just be built from scratch within the module,
(my template idea was not working and kinda unintuitive) but the dialog and
editor should not interact. the configuration module should be all that is
needed. also a global config module based on wxconfig is a good idea imo, i
remember talking about a separated one but been to long to remember details.

ill update the editor module docs once i have a decent bit of code figured
out. project file docs ill do before writing code since it will be easier
with wxdev and code::blocks to look at. i think all config, wxform, project,
workspace, whatever should be xml. i think we decided on that anyway. we can
use the wxXMLconfig class on wxforum until its added to wxWidgets unless
they already did i haven't looked. i did check that it works fine. also
other xml can be done in wxXML i think they have that class stable now.
(wasn't in 2.6, i think it is in 2.8)

and for the form designer i have an idea on spacers, instead of a spacer
panel, since we are going for wysiwyg it should be nonvisual somehow. im
thinking if the ide gui bits needed for the form designer are far enough
along creating the designer will be easier. also for a start point on using
a compiler down the line maybe code::blocks code can be used until we can
write the appropriate makefile generators and stuff. possibly the debugger
too, but that is a good ways off yet. also maybe a small delphi program can
be used to convert the delphi wxform icons/images to image files/xpm
probably by default. then placed in the images directory for use. the wxform
format for the c++ designer is probably better off not being based on xrc
format. its kinda limited and we don't have enough flexability to do
everything we need. since designer code mangling is xml based we could
hypothetically support win32 or gtk but they wouldnt be wysiwyg obviously.
also a gui widget can be several classes in code since the widget doesn't
export code the xml does, so we just need a way to identify the gui widget
in the xml to allow for different class code, also gui plugins would make
sense.

im leaving out the plugin stuff since i dont know how to do it. obviously
the gui part is not as big an issue since its basically injecting into the
gui but the other bits are out of my league. if the main form is written
correctly adding the plugin parts wont be too tough and it gives some place
to start drafting the interface.

ill take a look at trac and put up some notes maybe. that covers what ive
been thinking about lately. i still need to put a machine together since my
last box fried and i gave away the monitor. a bit short sighted i suppose
but ill live.

Nuklear Zelph

Re: [Wxdevide-devs] workspace definition

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

I like the XML idea. I wonder if it might be good to define the XML file for
the workspace so that it is compatible with bakefile. Bakefile uses XML to
define the build and will autogenerate native makefiles for the usual
compilers out there. It could kill 2 birds with one stone.

http://www.bakefile.org/doc/ch02.html#sec.helloworld

-Tony


On Wed, Mar 2, 2011 at 10:33 AM, M Nealon <mal...@gm...> wrote:

> Hello all,
>
> Here is my first idea for a workspace.
>
> I think we should keep it simple to begin with.
>
> So here is my definition for wxDevIDE_Workspace_file:
>
> A workspace file is simply an xml file, which consists of  a list of
> projects.
>
> When wxDevIDE starts there will be a default workspace loaded. It will have
> no projects included.
>
> We will use the wxXML class, since one of my main intentions is to use the
> wxWidgets libraries as much as possible.
>
> Initially ALL a workspace file will be is a list of projects. Since a
> workspace might have several projects, I think we might need to limit it to
> having a single executable project. So we would have workspace containing
> many libraries but only a single executable. Of course a user may wish to
> create a number of executables, and to this end we may need to revisit this.
> Or we could have a single workspace containing several workspaces in order
> to allow the user to achieve the several executable option. Or we simply
> allow the user to select an active project within the workspace and only
> allow that project to be debugged/run from the IDE.
>
> I'll see if I can get some code running in the next couple of days.
>
> Any comments?
>
> regards
> Mal
>
>
> ------------------------------------------------------------------------------
> Free Software Download: Index, Search & Analyze Logs and other IT data in
> Real-Time with Splunk. Collect, index and harness all the fast moving IT
> data
> generated by your applications, servers and devices whether physical,
> virtual
> or in the cloud. Deliver compliance at lower cost and gain new business
> insights. http://p.sf.net/sfu/splunk-dev2dev
> _______________________________________________
> Wxdevide-devs mailing list
> Wxd...@li...
> https://lists.sourceforge.net/lists/listinfo/wxdevide-devs
>
>

[Wxdevide-devs] Project Definition

[M N. <mal...@gm...>]

Hi All,

After thinking about the workspace file format a little, I have given some
thought to the project file format.

Again the format will be an XML file generated using wxXML if possible.

The project file format will change as the program develops, but I think
that the simplest version to begin with will be a list of source files,
separated into include files and src files for the project. OR should we
save all information as can be seen in the Project Options dialog? Thinking
about this I think so.

So we abandon the wxDevC++ ini file structure, adding an import function on
the menu, and replace this with an xml file representation of the same
information. Again I'll try and get some code running within  a couple of
days.

I'll try to get the import function working too, so we can import the
wxDevIDE project into itself.

And ideas? Thoughts?

Regards
Mal

[Wxdevide-devs] workspace definition

[M N. <mal...@gm...>]

Hello all,

Here is my first idea for a workspace.

I think we should keep it simple to begin with.

So here is my definition for wxDevIDE_Workspace_file:

A workspace file is simply an xml file, which consists of  a list of
projects.

When wxDevIDE starts there will be a default workspace loaded. It will have
no projects included.

We will use the wxXML class, since one of my main intentions is to use the
wxWidgets libraries as much as possible.

Initially ALL a workspace file will be is a list of projects. Since a
workspace might have several projects, I think we might need to limit it to
having a single executable project. So we would have workspace containing
many libraries but only a single executable. Of course a user may wish to
create a number of executables, and to this end we may need to revisit this.
Or we could have a single workspace containing several workspaces in order
to allow the user to achieve the several executable option. Or we simply
allow the user to select an active project within the workspace and only
allow that project to be debugged/run from the IDE.

I'll see if I can get some code running in the next couple of days.

Any comments?

regards
Mal

Re: [Wxdevide-devs] Plugin Architecture

[M N. <mal...@gm...>]

On Tue, Feb 1, 2011 at 11:27 PM, Esteban Aguilar B. <nab...@ya...>wrote:

> I have already suggested this long ago, but since it's been brought up....,
> why not just take one of these projects (ie. Code::Blocks) and modify it's
> GUI and behavior to become as close as possible as wxDevCpp (meaning, easier
> to use)? The thing could be repackaged in a user friendly installer that
> let's you compile examples right away (last time I checked, C::B required
> manual configuration of system variables or something, linux MAKE style
> configuration before being able to compile something, so, many people
> preferred our user friendly setup; but I guess this could be no longer the
> case).
>
>
>

I have considered this too. My idea was to use wxDevC++ to generate the
forms, and then adapt C::B code to "fit"  our IDE. I still think that this
is the way to go for a small development team, since the IDE is what the
user seed, not the underlying code.

I of course know that C::B is open source and we can use their code for our
own IDE, and this might very well be the way to go in the short term.

I would suggest, if you feel like it, to have a quick look and see how
difficult it might be. If this looks like the way to go in the short term
then I am all for it.

Regards
Mal

Re: [Wxdevide-devs] Plugin Architecture

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

Mal and I were thinking of starting by just creating a visual designer
plugin for CodeLite. So no complete IDE just yet. As far as I know, CodeLite
does not currently have a visual designer for wxWidgets.

-Tony


On Tue, Feb 1, 2011 at 2:27 PM, Esteban Aguilar B. <nab...@ya...>wrote:

> I have already suggested this long ago, but since it's been brought up....,
> why not just take one of these projects (ie. Code::Blocks) and modify it's
> GUI and behavior to become as close as possible as wxDevCpp (meaning, easier
> to use)? The thing could be repackaged in a user friendly installer that
> let's you compile examples right away (last time I checked, C::B required
> manual configuration of system variables or something, linux MAKE style
> configuration before being able to compile something, so, many people
> preferred our user friendly setup; but I guess this could be no longer the
> case).
>
>
> Some Advantages:
>
> -No wheel reinvention.
>
> -No initial years long open-source-project curve, where nothing get's
> released and people become increasingly uninterested and were there's a huge
> risk of the project getting abandoned, waisting all the work done, plus the
> bigger risk of becoming obsolete.
>
> -Code reutilization (plugin compatability) potentially in 2 ways (the
> original project could be patched, or the new work re-merged at some point).
>
> -Potentially, compatibility could be maintained between the file formats
> for projects or solutions of the original project (C::B) and wxDevIDE, so
> the user base is bigger.
>
> -other things I guess.
>
>
> Disadvantages:
>
> -Not as fun?
>
> -Modifying C::B or whatever could be harder that thought?
>
>
> In any case, and since I may not even participate, these are just my 2
> cents as someone who would appreciate a wxDevIDE project that becomes real
> in my lifetime :)
>
>
>
> --- El *dom, 1/30/11, M Nealon <mal...@gm...>* escribió:
>
>
> De: M Nealon <mal...@gm...>
> Asunto: [Wxdevide-devs] Plugin Architecture
> A: "wxDevIde Developers" <wxd...@li...>
> Fecha: domingo, 30 de enero de 2011, 05:32 am
>
>
> Anybody have any ideas as to how we proceed here?
>
> I suggest that we take a look at CodeLite and Code::Blocks and use either
> one of theirs or merge the two into our own.
>
> Unless someone else has any suggestions?
>
>
> Regards
> Mal
>
> -----Adjunto en línea a continuación-----
>
>
>
> ------------------------------------------------------------------------------
> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> Finally, a world-class log management solution at an even better
> price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> February 28th, so secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsight-sfd2d
>
> -----Adjunto en línea a continuación-----
>
>
> _______________________________________________
> Wxdevide-devs mailing list
> Wxd...@li...<http://mc/compose?to=Wxd...@li...>
> https://lists.sourceforge.net/lists/listinfo/wxdevide-devs
>
>
>
>
> ------------------------------------------------------------------------------
> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> Finally, a world-class log management solution at an even better
> price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> February 28th, so secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsight-sfd2d
> _______________________________________________
> Wxdevide-devs mailing list
> Wxd...@li...
> https://lists.sourceforge.net/lists/listinfo/wxdevide-devs
>
>

Re: [Wxdevide-devs] Plugin Architecture

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

I have already suggested this long ago, but since it's been brought up...., why not just take one of these projects (ie. Code::Blocks) and modify it's GUI and behavior to become as close as possible as wxDevCpp (meaning, easier to use)? The thing could be repackaged in a user friendly installer that let's you compile examples right away (last time I checked, C::B required manual configuration of system variables or something, linux MAKE style configuration before being able to compile something, so, many people preferred our user friendly setup; but I guess this could be no longer the case).
Some Advantages:-No wheel reinvention.-No initial years long open-source-project curve, where nothing get's released and people become increasingly uninterested and were there's a huge risk of the project getting abandoned, waisting all the work done, plus the bigger risk of becoming obsolete.-Code reutilization (plugin compatability) potentially in 2 ways (the original project could be patched, or the new work re-merged at some point).-Potentially, compatibility could be maintained between the file formats for projects or solutions of the original project (C::B) and wxDevIDE, so the user base is bigger.-other things I guess.
Disadvantages:-Not as fun?-Modifying C::B or whatever could be harder that thought?
In any case, and since I may not even participate, these are just my 2 cents as someone who would appreciate a wxDevIDE project that becomes real in my lifetime :) 

--- El dom, 1/30/11, M Nealon <mal...@gm...> escribió:

De: M Nealon <mal...@gm...>
Asunto: [Wxdevide-devs] Plugin Architecture
A: "wxDevIde Developers" <wxd...@li...>
Fecha: domingo, 30 de enero de 2011, 05:32 am

Anybody have any ideas as to how we proceed here?
I suggest that we take a look at CodeLite and Code::Blocks and use either one of theirs or merge the two into our own. 
Unless someone else has any suggestions?


RegardsMal

-----Adjunto en línea a continuación-----

------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
February 28th, so secure your free ArcSight Logger TODAY! 
http://p.sf.net/sfu/arcsight-sfd2d
-----Adjunto en línea a continuación-----

_______________________________________________
Wxdevide-devs mailing list
Wxd...@li...
https://lists.sourceforge.net/lists/listinfo/wxdevide-devs



      

[Wxdevide-devs] Plugin Architecture

[M N. <mal...@gm...>]

Anybody have any ideas as to how we proceed here?

I suggest that we take a look at CodeLite and Code::Blocks and use either
one of theirs or merge the two into our own.

Unless someone else has any suggestions?


Regards
Mal

Re: [Wxdevide-devs] Designer Development

[<Nuk...@gm...>]

I have not done or thought anything about it in a while. I did realize that  
we could use wxObject and IsOfClass() as a designer tree base of some kind.  
I think storing images in a folder and using the name in place of ascii  
code is a better approach unless we just save everything as an xpm. that  
however lacks some features like alpha blending. That is all i really  
figured out so far. i pretty much have given up on software development so  
i wont be too useful.

Nuklear

On Jan 29, 2011 8:52am, M Nealon <mal...@gm...> wrote:
> Hi All (Tony?),

> I am currently investigating the designer for wxDevIDE.


> One point that I am unsure about is in fact the importing of wxform  
> information into the designer (getting ahead of myself here I know). One  
> of the problems is the icons for the menu (possibly anything with  
> images). The information is saved in the wxform file as a series of ascii  
> strings. What someone needs to do (looking at everyone else here) is to  
> investigate some sort of export function which will export the wxform  
> information into a format which we can then use for the new wxidefrm form.



> What I suggest is that we create our own wxform format (which I have  
> chosen to call wxidefrm which is a reasonably faithful representation of  
> the current wxform format but with images contained within in some  
> standard easily used/identified format.



> I have to do a lot of investigation wrt the designer, but I might be able  
> to make a start in getting something into an IDE.


> What I intend to do as a first step is to make a start on the SDK for our  
> plugins (of which the designer is just one) as I develop the designer,  
> unless anyone has any ideas as to the SDK for the plugins (hopefully with  
> sample code - then PLEASE provide them).



> However, I do get the impression that we have all left the project and  
> are just letting it die, is this so?


> What I/we could do is develop the designer as a plugin for CodeLite  
> and/or Code::Blocks until we get our own IDE up and running, but if there  
> is no interest in developing wxDevIDE then I don't think that there is  
> much point to investigate implementing some sort of plugin architecture,  
> and I should just concentrate on developing the designer for some other  
> IDE (CodeLite and/or Code::Blocks) that already has a plugin architecture  
> in place.



> I suppose what I am really asking is "is wxDevIDE dead?", and if so what  
> do we as a group (if we are still a group) or I as an individual do now?


> regards
> Mal

[Wxdevide-devs] Designer Development

[M N. <mal...@gm...>]

Hi All (Tony?),

I am currently investigating the designer for wxDevIDE.

One point that I am unsure about is in fact the importing of wxform
information into the designer (getting ahead of myself here I know). One of
the problems is the icons for the menu (possibly anything with images). The
information is saved in the wxform file as a series of ascii strings. What
someone needs to do (looking at everyone else here) is to investigate some
sort of export function which will export the wxform information into a
format which we can then use for the new wxidefrm form.

What I suggest is that we create our own wxform format (which I have chosen
to call wxidefrm which is a reasonably faithful representation of the
current wxform format but with images contained within in some standard
easily used/identified format.

I have to do a lot of investigation wrt the designer, but I might be able to
make a start in getting something into an IDE.

What I intend to do as a first step is to make a start on the SDK for our
plugins (of which the designer is just one) as I develop the designer,
unless anyone has any ideas as to the SDK for the plugins (hopefully with
sample code - then PLEASE provide them).

However, I do get the impression that we have all left the project and are
just letting it die, is this so?

What I/we could do is develop the designer as a plugin for CodeLite and/or
Code::Blocks until we get our own IDE up and running, but if there is no
interest in developing wxDevIDE then I don't think that there is much point
to investigate implementing some sort of plugin architecture, and I should
just concentrate on developing the designer for some other IDE (CodeLite
and/or Code::Blocks) that already has a plugin architecture in place.

I suppose what I am really asking is "is wxDevIDE dead?", and if so what do
we as a group (if we are still a group) or I as an individual do now?

regards
Mal

Re: [Wxdevide-devs] Build on windows 7 64bit

[M N. <mal...@gm...>]

On Sun, Sep 5, 2010 at 7:30 PM, Tony Reina <re...@al...> wrote:

> Awesome. Yes, it would be nice if we could get a version that compiles
> itself. However, don't forget about us 32-bit users.
>
> -Tony
>
>
> On Sun, Sep 5, 2010 at 10:26 AM, M Nealon <mal...@gm...>wrote:
>
>> Hello All,
>>
>> After a bit of playing around, I managed to get the source code to build
>> and run under windows 7 64 bit, using the mingw-w64 (64 bit) compiler, and
>> wxwidgets SVN..
>>
>>
Don't worry, it builds just fine on windows 7 home premium 32 bit. If memory
serves I built it using the compiler with wxDevC++ .

I'll look into the scintilla stuff first, although if I knew enough about
getting the compiler to work from the IDE itself, I'd prefer to do that
first. I really want a version that can compile itself. Then we can move the
project forward.

I built the wxWIdgets library as a monolithic dll. I wasn't prepared for how
long it would take, but I also didn't have enough free space for the swap
file (4GB) so I'm not too surprised. We need the library as a dll since we
want to have an open architecture for plugin development.

Hope someone else can help with getting the compiler running. Even under 32
bit this would be extremely beneficial.

Regards
Mal

Re: [Wxdevide-devs] Build on windows 7 64bit

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

Awesome. Yes, it would be nice if we could get a version that compiles
itself. However, don't forget about us 32-bit users.

-Tony


On Sun, Sep 5, 2010 at 10:26 AM, M Nealon <mal...@gm...> wrote:

> Hello All,
>
> After a bit of playing around, I managed to get the source code to build
> and run under windows 7 64 bit, using the mingw-w64 (64 bit) compiler, and
> wxwidgets SVN..
>
> I needed to build wxwidgets using the 64bit compiler, because I couldn't
> get any of the 32 bit versions to compile correctly.
>
> I needed to adapt a wxwidgets makefile to get the build compiling
> correctly, but at least it builds.
>
> Not sure what I can do from here, probably see if I can get the code to
> compile a file/build a project. What I really wanted to do was get the code
> compiling itself, but this will have to wait for a while (I am in the
> process of preparing to move house so time is short).
>
> Hope all are well, and we might actually get to see some progress in the
> project.
>
> Best regards
> Mal
>
>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> Wxdevide-devs mailing list
> Wxd...@li...
> https://lists.sourceforge.net/lists/listinfo/wxdevide-devs
>
>

[Wxdevide-devs] Code builds on windows 7 64bit using mingw-w64 compiler

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

Hello All,

After a bit of playing around, I managed to get the source code to build and
run under windows 7 64 bit, using the mingw-w64 (64 bit) compiler, and
wxwidgets SVN..

I needed to build wxwidgets using the 64bit compiler, because I couldn't get
any of the 32 bit versions to compile correctly.

I needed to adapt a wxwidgets makefile to get the build compiling correctly,
but at least it builds.

Not sure what I can do from here, probably see if I can get the code to
compile a file/build a project. What I really wanted to do was get the code
compiling itself, but this will have to wait for a while (I am in the
process of preparing to move house so time is short).

Hope all are well, and we might actually get to see some progress in the
project.

Best regards
Mal

[Wxdevide-devs] Build on windows 7 64bit

[M N. <mal...@gm...>]

Hello All,

After a bit of playing around, I managed to get the source code to build and
run under windows 7 64 bit, using the mingw-w64 (64 bit) compiler, and
wxwidgets SVN..

I needed to build wxwidgets using the 64bit compiler, because I couldn't get
any of the 32 bit versions to compile correctly.

I needed to adapt a wxwidgets makefile to get the build compiling correctly,
but at least it builds.

Not sure what I can do from here, probably see if I can get the code to
compile a file/build a project. What I really wanted to do was get the code
compiling itself, but this will have to wait for a while (I am in the
process of preparing to move house so time is short).

Hope all are well, and we might actually get to see some progress in the
project.

Best regards
Mal

[Wxdevide-devs] contrib changes

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

A few months ago someone sent in some contributer changes for the C++
version of wxDevIDE. I WAS going to look through them and update as/if
necessary or see what I thought. Now having switched over to wxWidgets 2.9.1
myself I don't know if its a good idea to port the svn sources over too or
not. What did we decide about building against 3.x api? I can use wx2.8 to
work on it, if we still want to go that route since wx3 isn't official yet
anyway.

If anyone else wants to look at the files I was sent just ask, I have not
yet messed with any of it or know what it is yet. On other notes as I
mentioned to Tony about wxWidgets in a dll and using it in Delphi for an
intermediate step to the full version of the C++ designer. (by using Delphi
dev as the ide for now) What does everyone else think? Esteban has some
experience and did manage some kind of a c++ plugin support. What does this
actually take to do? Obviously the menubar stuff and all can be Delphi code
and just the actual RAD panel is in C++. I don't know what it takes to
"wrap" the functions or anything so....


Nuklear

Re: [Wxdevide-devs] wxInstance from dll

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

So is the idea that we could link wxWidgets as a DLL and upgrade the
wxWidgets DLL separately whenever the wxWidgets guys generate a new version?

-Tony


On Sun, Aug 8, 2010 at 6:20 PM, Nuklear Zelph <nuk...@gm...>wrote:

> i don't know if this was available in 2.8 but i have switched over to 2.9.1
> (since it seems to work unlike the previous one) and while looking through
> samples i found the "dll" sample. it seems someone has put some effort into
> making wxWidgets launchable from a dll, in such case does not need winmain.
> i don't know if it would work with delphi and i don't know if we want to try
> but i remember a past conversation about this very idea.
>
> Nuklear
>

[Wxdevide-devs] wxInstance from dll

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

i don't know if this was available in 2.8 but i have switched over to 2.9.1
(since it seems to work unlike the previous one) and while looking through
samples i found the "dll" sample. it seems someone has put some effort into
making wxWidgets launchable from a dll, in such case does not need winmain.
i don't know if it would work with delphi and i don't know if we want to try
but i remember a past conversation about this very idea.

Nuklear

Re: [Wxdevide-devs] status

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

Yes, the capturemouse method would have been pretty nice. I had hoped to
create a generic widget template that would inherit the component-specific
methods and properties when instantiated. However, if the method really is a
"no no", then we probably don't want to go down that path (even if it works
well on Windows).

-Tony


On Thu, Jul 1, 2010 at 3:16 PM, Nuklear Zelph <nuk...@gm...>wrote:

> that explains why wxsmith and wxglade and others are designed the way they
> are. that also makes a drag n drop wysiwyg like we have difficult. i have an
> idea that might let us get around using capture mouse and such. its kinda
> vague though ill do some messing around and see what if anything i can come
> up with. ill get back later on what i find or if its a lost cause.
>
> Nuklear
>
>
>
>
> On Thu, Jul 1, 2010 at 8:37 AM, Tony Reina <re...@al...> wrote:
>
>>
>>
>>> i don't know what if any work/ideas have been put into the form designer.
>>> if anyone has lets hear about it. i know Tony was looking at the
>>> wxResizableButton, and it fails on gtk, was any solution found or is it
>>> still in the air? also has anyone done enough work with the wxXML class to
>>> know if it can handle what xml we need or do we quite know yet?
>>>
>>
>>
>> I was never able to find a solution for gtk. From what I discovered, the
>> CaptureMouse trick is only legal on windowed controls. Using it on a
>> wxButton is not recommended even though it may work on some platforms.
>>
>> -Tony
>>
>>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Wxdevide-devs mailing list
> Wxd...@li...
> https://lists.sourceforge.net/lists/listinfo/wxdevide-devs
>
>

Re: [Wxdevide-devs] status

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

that explains why wxsmith and wxglade and others are designed the way they
are. that also makes a drag n drop wysiwyg like we have difficult. i have an
idea that might let us get around using capture mouse and such. its kinda
vague though ill do some messing around and see what if anything i can come
up with. ill get back later on what i find or if its a lost cause.

Nuklear



On Thu, Jul 1, 2010 at 8:37 AM, Tony Reina <re...@al...> wrote:

>
>
>> i don't know what if any work/ideas have been put into the form designer.
>> if anyone has lets hear about it. i know Tony was looking at the
>> wxResizableButton, and it fails on gtk, was any solution found or is it
>> still in the air? also has anyone done enough work with the wxXML class to
>> know if it can handle what xml we need or do we quite know yet?
>>
>
>
> I was never able to find a solution for gtk. From what I discovered, the
> CaptureMouse trick is only legal on windowed controls. Using it on a
> wxButton is not recommended even though it may work on some platforms.
>
> -Tony
>
>

Re: [Wxdevide-devs] status

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

>
> i don't know what if any work/ideas have been put into the form designer.
> if anyone has lets hear about it. i know Tony was looking at the
> wxResizableButton, and it fails on gtk, was any solution found or is it
> still in the air? also has anyone done enough work with the wxXML class to
> know if it can handle what xml we need or do we quite know yet?
>


I was never able to find a solution for gtk. From what I discovered, the
CaptureMouse trick is only legal on windowed controls. Using it on a
wxButton is not recommended even though it may work on some platforms.

-Tony