wxcode-users — Submission, Questions, Information

Re: [wxCode-users] bakefile gdiplus lib

[Francesco M. <f18...@ya...>]

Hi Klaas,

klaas.holwerda ha scritto:
> Francesco,
> 
> I updated from CVS, but the linking problem is still there (gdiplus.lib 
> is not in the makefile.vc.
> And with nmake it is a problem.
Yes, I see. It looks like John still has not committed his changes to the 
bakefiles... John, if you want, I can do it...


> Next i discovered that wxLua and wxstedit follow different ways to set 
> unicode and debug.
> 
> wxstedit: nmake -f makefile.vc WX_UNICODE=1 WX_DEBUG=1
> 
> wxLua & wxWidgets: nmake -f makefile.vc UNICODE=1 BUILD=debug
> 
> Why this difference??
yes, I know of this difference; the problem is that with wxLua we choose to 
explicitely rename the default wxpresets' options WX_DEBUG and WX_UNICODE into 
BUILD and UNICODE.

Originally in wxCode we chose to not use modified wxpresets as it was too 
confusing for the various maintainers.
In wxCode this would be possible too, now (without having to use modified 
wxpresets). However IIRC I asked opinions about this on this mailing list and it 
was agreed that it was confusing to "suddenly" change WX_DEBUG=>BUILD as wxCode 
users were already used to WX_DEBUG and not BUILD (even if it's the name used by 
wx).

> It is rather confusing. Because for that was the reason i thought the 
> naming of the libs went wrong, but it is oke.
> I would not mind that all of them worked the same, or at least wxlua and 
> wxCode stuff.
I agree it's confusing and I would like to change it. However other maintainers 
should agree on this, too...

Maybe wx3.0 will be the good occasion to do this (as we will need some other 
[small] adjustments to the build system).

Francesco

Re: [wxCode-users] bakefile gdiplus lib

[klaas.holwerda <ng...@kl...>]

Francesco,

I updated from CVS, but the linking problem is still there (gdiplus.lib 
is not in the makefile.vc.
And with nmake it is a problem.
Next i discovered that wxLua and wxstedit follow different ways to set 
unicode and debug.

wxstedit: nmake -f makefile.vc WX_UNICODE=1 WX_DEBUG=1

wxLua & wxWidgets: nmake -f makefile.vc UNICODE=1 BUILD=debug

Why this difference??
It is rather confusing. Because for that was the reason i thought the 
naming of the libs went wrong, but it is oke.
I would not mind that all of them worked the same, or at least wxlua and 
wxCode stuff.

Francesco Montorsi wrote:
>> Francesco Montorsi wrote:
>>     
>>
> well, that's ok for me however: if you compile with opengl, it doesn't mean that 
> any app using wx-config needs wx openGL library, isn't it?
> If an app needs it, it can use "wx-config --libs gl" :)
>   
Oke forgot that one again, thanks for reminding :-)
Regards,

Klaas

Re: [wxCode-users] bakefile gdiplus lib

[Francesco M. <f18...@ya...>]

klaas.holwerda ha scritto:
> Francesco Montorsi wrote:
>> I think it should just be fine. I think that in fact we have no changes we need 
>> to preserve in wxCode wxpresets bakefiles respect official wxpresets. We keep a 
>> copy there just to facilitate baking for wxCode maintainers...
>> so that probably we can just overwrite wxCode's wxpresets with wx2.8.10 
>> wxpresets...
>>   
> I hope so, but wxWidgets has its problems too when it comes to setting 
> extra options :-)
> E.g. when i compile --with-opengl on linux,   wxconfig --libs does not 
> include the  generated wxWidgets opengl library.
well, that's ok for me however: if you compile with opengl, it doesn't mean that 
any app using wx-config needs wx openGL library, isn't it?
If an app needs it, it can use "wx-config --libs gl" :)


> So is it (wxpresets update) the same for/in wxLua to solve this problem??
yes, I think it's required also for wxLua... John, perhaps you already fixed it 
in wxLua, too?

Francesco

Re: [wxCode-users] [wxCode users] problems with file uploads

[Francesco M. <f18...@ya...>]

Hi Luciano,

Luciano C. ha scritto:
> I am having troubles uploading files to the website and documentation space of wxCode.
> The docs on wxCode's maintainer guide says:
> 
>   Hostname: shell.sourceforge.net
>     Username: yourSFusername
>     Folder where you should copy your docs: /home/groups/w/wx/wxcode/htdocs/docs/YOURCOMPNAME
indeed, the doc is old; SF keeps changing/revolutionizing all their services 
every 3-4 months...

I've changed this page:
http://wxcode.sourceforge.net/template.php

with a link to their shell service docs.


> I am using Filezilla 3.2.0 but the connection cannot be established.
> On SF's docs it seems that the correct host to connect to is:
> 
> web.sourceforge.net
yes, this would be their suggested way for uploading stuff to web; you can do 
that also using their shell service however and that easier to use IMO...


> Using this one  I can connect and navigate the directory tree until:
> 
> /home/groups/w/wx/
> 
> When I try to open the wxcode subfolder I get an error message like this:
> 
>   Directory /home/groups/w/wx/wxcode: permission denied
> 
> Note that I did upload files in the past.
hmmm, can you try the shell service system?
Permissions should be ok as far as you're part of the "wxcode" unix group...

Francesco

[wxCode-users] [wxCode users] problems with file uploads

[Luciano C. <lu...@ma...>]

Hi,
I am having troubles uploading files to the website and documentation space of wxCode.
The docs on wxCode's maintainer guide says:

  Hostname: shell.sourceforge.net
    Username: yourSFusername
    Folder where you should copy your docs: /home/groups/w/wx/wxcode/htdocs/docs/YOURCOMPNAME
    

I am using Filezilla 3.2.0 but the connection cannot be established.
On SF's docs it seems that the correct host to connect to is:

web.sourceforge.net

Using this one  I can connect and navigate the directory tree until:

/home/groups/w/wx/

When I try to open the wxcode subfolder I get an error message like this:

  Directory /home/groups/w/wx/wxcode: permission denied

Note that I did upload files in the past.
Thanks.
Luciano



      

Re: [wxCode-users] bakefile gdiplus lib

[klaas.holwerda <ng...@kl...>]

Francesco Montorsi wrote:
> I think it should just be fine. I think that in fact we have no changes we need 
> to preserve in wxCode wxpresets bakefiles respect official wxpresets. We keep a 
> copy there just to facilitate baking for wxCode maintainers...
> so that probably we can just overwrite wxCode's wxpresets with wx2.8.10 
> wxpresets...
>   
I hope so, but wxWidgets has its problems too when it comes to setting 
extra options :-)
E.g. when i compile --with-opengl on linux,   wxconfig --libs does not 
include the  generated wxWidgets opengl library.
 
So is it (wxpresets update) the same for/in wxLua to solve this problem??

Regards,

Klaas

Re: [wxCode-users] bakefile gdiplus lib

[klaas.holwerda <ng...@kl...>]

Francesco Montorsi wrote:
> and WXLIBPOSTFIX seems to be set correctly (i.e. contains 'u' and 'd' flags when 
> required) so that I think everything is ok.
>   
Is it oke now, are was it oke before? I build today with wxstedit (not 
updated recently yet fromCVS), but it was wrong when using "nmake".
So maybe there is something sneaky going on here.
Will check once again.

Best Regards,

Klaas

Re: [wxCode-users] bakefile gdiplus lib

[Francesco M. <f18...@ya...>]

Hi John, Klaas,

John Labenski ha scritto:
> I don't see how to automatically test for this, but we could add a 
> condition USE_GDIPLUS as wxWidgets does. Francesco, do you think this 
> would work?
> 
...
> Put this after the line "<sys-lib>odbc32</sys-lib>" in wx.blk
> <sys-lib>$(GDIPLUS_LIB)</sys-lib>
> 
> ============================================
> So I tried puttting this into wxCode's wx_win32.bkl and the output code 
> looks ok, but it's not tested. The dsp and vcproj are unchanged, but the 
> makefile.vc <http://makefile.vc> should work.
I think it should just be fine. I think that in fact we have no changes we need 
to preserve in wxCode wxpresets bakefiles respect official wxpresets. We keep a 
copy there just to facilitate baking for wxCode maintainers...
so that probably we can just overwrite wxCode's wxpresets with wx2.8.10 
wxpresets...


>     A second bakefile related problem is that building debug and release of
>     wxstedit, both result in the same library name:
>     wcode_msw28_stedit
> 
>     But for debug it should generate:
> 
>     wcode_msw28d_stedit
> 
> 
> I have rebaked the wxstedit build files in CVS and I see that the dsp 
> files put a 'd' in for debug so I assume that the makefile.vc 
> <http://makefile.vc> should too.
Looking at the makefile.vc I see that the lib target is called:

..\lib\vc_$(____stedit_lib__DIRNAME_SHARED_SUFFIX_FILENAMES)\wxcode_msw$(WX_VERSION)$(WXLIBPOSTFIX)_stedit.lib

and WXLIBPOSTFIX seems to be set correctly (i.e. contains 'u' and 'd' flags when 
required) so that I think everything is ok.

Bye,
Francesco

Re: [wxCode-users] bakefile gdiplus lib

[John L. <jla...@gm...>]

On Sat, May 9, 2009 at 5:46 AM, klaas.holwerda <ng...@kl...> wrote:

> Hi,
>
> When i enable in wxWidgets in config.vc the next:
>
> # Link with gdiplus.lib? (Needed for wxGraphicsContext, will also set
> wxUSE_GRAPHICS_CONTEXT) [0,1]
> USE_GDIPLUS = 1
>
> this result in linking errors in wxstedit ( and later also in wxLua) and
> all other modules i presume.
> So i add in the makefile.vc by hand the missing gdiplus.lib.
>
> I wonder how  it would be possible to handle this directly in bakefile
> generated makefiles.
> For instance, build.cfg, contains the setting for USE_GDIPLUS, so it can
> be detected.
>

I don't see how to automatically test for this, but we could add a condition
USE_GDIPLUS as wxWidgets does. Francesco, do you think this would work?

-------------------------------------------
Ripped from wxWidget's 2.8.10 config.bkl to be put into wxCode's
wx_win32.blk

   <if cond="FORMAT!='autoconf'">
        <option name="USE_GDIPLUS">
            <values>0,1</values>
            <default-value>0</default-value>
            <description>
                Link with gdiplus.lib? (Needed for wxGraphicsContext, will
also set wxUSE_GRAPHICS_CONTEXT)
            </description>
        </option>
    </if>

<if cond="FORMAT_SUPPORTS_CONDITIONS=='0'">
    <if cond="FORMAT!='autoconf'"><set var="USE_GDIPLUS">0</set></if>
</if>

-------------------------------------------
Ripped from wxWidget's 2.8.10 common.bkl to be put into wxCode's
wx_win32.blk

<if cond="FORMAT!='autoconf'">
        <set var="GDIPLUS_LIB">
            <if cond="USE_GDIPLUS=='1'">gdiplus</if>
        </set>
</fi>

Put this after the line "<sys-lib>odbc32</sys-lib>" in wx.blk
<sys-lib>$(GDIPLUS_LIB)</sys-lib>

============================================
So I tried puttting this into wxCode's wx_win32.bkl and the output code
looks ok, but it's not tested. The dsp and vcproj are unchanged, but the
makefile.vc should work.

Index: presets/wx_win32.bkl
===================================================================
RCS file: /cvsroot/wxcode/wxCode/build/bakefiles/presets/wx_win32.bkl,v
retrieving revision 1.4
diff -b -u -2 -r1.4 wx_win32.bkl
--- presets/wx_win32.bkl        13 Feb 2008 14:00:13 -0000      1.4
+++ presets/wx_win32.bkl        11 May 2009 01:27:48 -0000
@@ -35,5 +35,23 @@
     <!--    comments for more info.    -->

+   <if cond="FORMAT!='autoconf'">
+        <option name="USE_GDIPLUS">
+            <values>0,1</values>
+            <default-value>0</default-value>
+            <description>
+                Link with gdiplus.lib? (Needed for wxGraphicsContext, set
to the value of wxUSE_GRAPHICS_CONTEXT)
+            </description>
+        </option>
+    </if>
+
+    <if cond="FORMAT_SUPPORTS_CONDITIONS=='0'">
+        <if cond="FORMAT!='autoconf'"><set var="USE_GDIPLUS">0</set></if>
+    </if>

+    <if cond="FORMAT!='autoconf'">
+        <set var="GDIPLUS_LIB">
+            <if cond="USE_GDIPLUS=='1'">gdiplus</if>
+        </set>
+    </if>

     <!--                     HELPER VARIABLES                       -->
@@ -248,4 +266,5 @@
             <sys-lib>wsock32</sys-lib>
             <sys-lib>odbc32</sys-lib>
+            <sys-lib>$(GDIPLUS_LIB)</sys-lib>
         </if>



> A second bakefile related problem is that building debug and release of
> wxstedit, both result in the same library name:
> wcode_msw28_stedit
>
> But for debug it should generate:
>
> wcode_msw28d_stedit
>

I have rebaked the wxstedit build files in CVS and I see that the dsp files
put a 'd' in for debug so I assume that the makefile.vc should too.


>
> Francesco, are you able to fix that? ;-)
>
>
I hope he has time to look at the above.

-John

[wxCode-users] bakefile gdiplus lib

[klaas.holwerda <ng...@kl...>]

Hi,

When i enable in wxWidgets in config.vc the next:

# Link with gdiplus.lib? (Needed for wxGraphicsContext, will also set 
wxUSE_GRAPHICS_CONTEXT) [0,1]
USE_GDIPLUS = 1

this result in linking errors in wxstedit ( and later also in wxLua) and 
all other modules i presume.
So i add in the makefile.vc by hand the missing gdiplus.lib.

I wonder how  it would be possible to handle this directly in bakefile 
generated makefiles.
For instance, build.cfg, contains the setting for USE_GDIPLUS, so it can 
be detected.

A second bakefile related problem is that building debug and release of 
wxstedit, both result in the same library name:
wcode_msw28_stedit

But for debug it should generate:

wcode_msw28d_stedit

Francesco, are you able to fix that? ;-)

Regards,

Klaas

[wxCode-users] [ wxcode-Patches-2787693 ] [wxPlotCtrl] plotdraw.cpp: Warning on double -> int cast.

[SourceForge.net <no...@so...>]

Patches item #2787693, was opened at 2009-05-06 09:06
Message generated for change (Tracker Item Submitted) made by jansson
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=462818&aid=2787693&group_id=51305

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: CVS HEAD
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Peter Jansson (jansson)
Assigned to: Nobody/Anonymous (nobody)
Summary: [wxPlotCtrl] plotdraw.cpp: Warning on double -> int cast.

Initial Comment:
On lines 1171 and 1173 in /cvsroot/wxcode/wxCode/components/wxplotctrl/src/plotdraw.cpp my compiler complains that double returned values from the call to floor are converted to int. I attach a patch with an explicit static_cast<int> applied on the returned values.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=462818&aid=2787693&group_id=51305

Re: [wxCode-users] New component registration

[Francesco M. <f18...@ya...>]

Hi Jan,

lenin ha scritto:
> Hi all,
> two week ago, I submited a component named wxDemo. I filled out the 
> submission form and send it. Now I wait as the submission guide tells 
> me. But two weeks is a long time I think... Did i get something wrong?
nothing wrong.

Unfortunately since some time SF has disabled automatic email notifications and 
so we cannot know when someone submits a new component. I think this was written 
in the submission form somewhere (hinting the new maintainers to drop a note 
here ;)).

Btw I've revised your submission and everything seems ok. I've approved the 
compoenent and you can start uploading sources to the repository as per the 
Maintainer's Guide in wxCode website.

It looks a nice component (just one thing: if you commented the wx example 
sources it could be better to send diffs with them directly to wx so they can be 
integrated in wx official distribution... otherwise they may soon go out-of-sync 
with the official example sources of next wx versions).

Don't hesitate to drop here your questions if you're in trouble.

Francesco

Re: [wxCode-users] New component registration

[JánChudý <len...@gm...>]

lenin <lenintech@...> writes:

> 
> Hi all, two week ago, I submited a component named wxDemo. I filled out the
submission form and send it. Now I wait as the submission guide tells me. But
two weeks is a long time I think... Did i get something wrong?
> Component ID is 109. Thanks..

Sorry, number 109 is my maintainer ID not the component ID...

[wxCode-users] New component registration

[lenin <len...@gm...>]

Hi all,
two week ago, I submited a component named wxDemo. I filled out the
submission form and send it. Now I wait as the submission guide tells me.
But two weeks is a long time I think... Did i get something wrong?
Component ID is 109. Thanks..

Re: [wxCode-users] Using wxPdfDocument to export a simple GDI generated documents to PDF

[Ulrich T. <ulr...@gm...>]

Peter,

>> wxPdfDocument's support of WMF files is limited. Not all GDI commands
>> are supported. Especially font support is lacking.
> 
> I saw that, but thought it was unlikely to matter - I'm just using
> TextOut and DrawLine. We're talking about very simple documents.

Unfortunately TextOut is one of the GDI commands currently *not* 
supported by wxPdfDocument. Better WMF support is on my to-do list, but 
with relatively low priority.

>> There exist low cost solutions for WMF to PDF conversion. You might even
>> consider to use an open source solution like ImageMagick.
> 
> I couldn't find any that I'd consider low cost - perhaps we have
> different definitions of low cost. I would consider perhaps €200 or
> €300 an acceptable amount to pay. I can find plenty of utilities (as
> oppose to libraries) that do it though.

We have about the same definition of low cost, but you are right I had 
utilities in mind.

> I could find this, but it seems fairly crappy:
> http://www.soft-album.com/Development/Components-Libraries/Image-to-PDF-Dynamic-Link-Library-6428-Review.html
> . I'd like to have source code, and they are suspiciously reticent
> about whether or not they provide it.

As I understand it they only provide the DLL. No source code.

> ImageMagick looks good, but I'm not sure I want to use such a
> monolithic library - I already use FreeImage+.
> 
> So, looks like I'll be using some commercial library (there is
> something about these commercial library sites that puts me
> off.....they have the look of snake oil salesmen).

Well, that's one of the reasons I started to develop wxPdfDocument. ;-)

Regards,

Ulrich

Re: [wxCode-users] Using wxPdfDocument to export a simple GDI generated documents to PDF

[Peter G. <pet...@gm...>]

Ulrich,


Thanks for your help, and thanks for getting back to me.

> wxPdfDocument's support of WMF files is limited. Not all GDI commands
> are supported. Especially font support is lacking.

I saw that, but thought it was unlikely to matter - I'm just using
TextOut and DrawLine. We're talking about very simple documents.

>> The only other way that I can find of doing this entails purchasing
>> an extremely overpriced licence for a commercial library.
>
> There exist low cost solutions for WMF to PDF conversion. You might even
> consider to use an open source solution like ImageMagick.


I couldn't find any that I'd consider low cost - perhaps we have
different definitions of low cost. I would consider perhaps €200 or
€300 an acceptable amount to pay. I can find plenty of utilities (as
oppose to libraries) that do it though.

I could find this, but it seems fairly crappy:
http://www.soft-album.com/Development/Components-Libraries/Image-to-PDF-Dynamic-Link-Library-6428-Review.html
. I'd like to have source code, and they are suspiciously reticent
about whether or not they provide it.

ImageMagick looks good, but I'm not sure I want to use such a
monolithic library - I already use FreeImage+.

So, looks like I'll be using some commercial library (there is
something about these commercial library sites that puts me
off.....they have the look of snake oil salesmen).

Regards,
Peter Geoghegan

Re: [wxCode-users] Using wxPdfDocument to export a simple GDI generated documents to PDF

[Ulrich T. <ulr...@gm...>]

Hi Peter,

> I'm maintaining an MFC application, and I'd like to be able to export
> some simple GDI generated documents to PDF. I see that wxPdfDocument
> has the capability of reading a Windows metafile (which essentially
> consists of a series of GDI function calls and their parameters):

wxPdfDocument's support of WMF files is limited. Not all GDI commands 
are supported. Especially font support is lacking.

> It ought to be possible for me to serialise my document as a windows
> Metafile using some MFC facility, perhaps to a temp directory, and
> subsequently open that file using bool wxPdfDocument::Image.
> 
> Is this practical, sensible and possible? How tightly coupled is
> wxPdfDocument to WxWidgets?

wxPdfDocument makes intensive use of the wxWidgets core library (for 
handling file streams, GIF images, stream compression and so on), so you 
can't use it without the wxWidgets library itself. Of course you could 
create a stand-alone command line utility which could perform the WMF to 
PDF conversion task and call this utility via system call 
(CreateProcess) from your own application.

> The only other way that I can find of doing this entails purchasing 
> an extremely overpriced licence for a commercial library.

There exist low cost solutions for WMF to PDF conversion. You might even 
consider to use an open source solution like ImageMagick.

Regards,

Ulrich

[wxCode-users] Using wxPdfDocument to export a simple GDI generated documents to PDF

[Peter G. <pet...@gm...>]

Hello,

I'm maintaining an MFC application, and I'd like to be able to export
some simple GDI generated documents to PDF. I see that wxPdfDocument
has the capability of reading a Windows metafile (which essentially
consists of a series of GDI function calls and their parameters):

http://wxcode.sourceforge.net/docs/wxpdfdoc/classwx_pdf_document.html
: See "bool wxPdfDocument::Image"

It ought to be possible for me to serialise my document as a windows
Metafile using some MFC facility, perhaps to a temp directory, and
subsequently open that file using bool wxPdfDocument::Image.

Is this practical, sensible and possible? How tightly coupled is
wxPdfDocument to WxWidgets? The only other way that I can find of
doing this entails purchasing an extremely overpriced licence for a
commercial library.

Regards,
Peter Geoghegan

Re: [wxCode-users] foldbar maintenance

[grhpas d. <gr...@gm...>]

OK! I've seen that I'm now the maintainer of the component. Thanks!

As you will see its an important part of the GUI of my application.

You've asked me earlier what the program was. Well its kind of a strange
idea, mainly because its an ambitious and optimistic attempt. But its going
to take a lot of time to develop. I am trying to make an office suite based
on ODF, using only C++,wxWidgets and relevant libraries. (You'll probably
call me crazy or smth but...)

http://grhpas.blogspot.com/

Re: [wxCode-users] foldbar maintenance

[Francesco M. <f18...@ya...>]

grhpas development ha scritto:
> Thanks!!!! Thats fast! I am number 108. So we can continue the process...
> 
>     Your wxCode maintainer ID is: 108
Ok, done.
You're now the maintainer of the foldbar component!

Please read the maintainers' guide in the wxCode website for more info about 
checking the repo out, committing changes, updating bakefiles, etc...

Drop here a question for any doubt and good luck!
Francesco

Re: [wxCode-users] foldbar maintenance

[grhpas d. <gr...@gm...>]

Thanks!!!! Thats fast! I am number 108. So we can continue the process...

> Your wxCode maintainer ID is: 108

Re: [wxCode-users] foldbar maintenance

[Francesco M. <f18...@ya...>]

grhpas development ha scritto:
> I've registered, but I've made an error, unfortunately.
> 
> I used a password containing an illegal character, which was accepted on 
> registration, but denied upon logging in. Is it possible to have my 
> registration info deleted so i could try a normal password?
yes, no problem. Done now.


Francesco

Re: [wxCode-users] foldbar maintenance

[grhpas d. <gr...@gm...>]

I've registered, but I've made an error, unfortunately.

I used a password containing an illegal character, which was accepted on
registration, but denied upon logging in. Is it possible to have my
registration info deleted so i could try a normal password?

Re: [wxCode-users] foldbar maintenance

[Francesco M. <f18...@ya...>]

Hi,

grhpas development ha scritto:
> Hi Francesco,
> 
> I haven't been expecting your email, due to the delay. I was thinking of 
> reapplying. 
sorry for that.

> I just registered as the maintainer, my SourceForge account ID is:
> 
> hephaestusp
ok, good; however I need you to subscribe also as wxCode maintainer:
http://wxcode.sourceforge.net/register.php
otherwise I cannot insert you in the wxCode DB :)

Once you've registered and you're logged in the wxCode website, you can see your 
wxCode maintainer ID in the page:

http://wxcode.sourceforge.net/edit.php

Just tell me and I'll bind you to foldbar component.


> I know contrib libraries have been removed. I  meant that it would be 
> great to have  the component fully functional [updated and released] for 
> wxWidgets 3.0. So I am willing!
ok! good!

> Glad to be able to contribute...
> 
> Just wait to see the project I am working on... Its going great so far 
> and it might cause some stir...
very interesting; I'm curious; can you give me some hints about your app? :)

Francesco

Re: [wxCode-users] foldbar maintenance

[grhpas d. <gr...@gm...>]

Hi Francesco,

I haven't been expecting your email, due to the delay. I was thinking of
reapplying.

I just registered as the maintainer, my SourceForge account ID is:

hephaestusp

I'm not sure to understand what this means... wxWidgets 3.0 won't have
> contrib
>
libraries (such as foldbar) anymore. Of course, this doesn't mean that
contrib

libraries are dead; they are available in wxCode for open development by
anyone

willing to do it :)

I know contrib libraries have been removed. I  meant that it would be great
to have  the component fully functional [updated and released] for wxWidgets
3.0. So I am willing!

Glad to be able to contribute...

Just wait to see the project I am working on... Its going great so far and
it might cause some stir...