wxcode-users — Submission, Questions, Information

Re: [wxCode-users] Bakefiles & wxCode's components

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

Hi,

> I've given you access rights to  wxCode/build.
I just commmitted to the build folder everything is required to use
bakefile with a component.
I'm open to any critic and suggestion...

All my components are now using those bakefiles; since I completed
the wxCode bakefiles, it required me about 10 minutes to convert
from old bakefiles & makefiles to the new wxCode bakefiles.
The Readme I put in the build dir should help in this process everyone
who wants to use it.

anyway, I still have to check the (very important) autoconf target; I'll 
have linux
access in short time.
I'll then provide a default configure.ac file ready to be configured for
the bakefiles of wxCode.

Francesco Montorsi


PS: should I update the complist.php file or someone is working
to make it automatic ?

[wxCode-users] Re: wxcode interface

[Otto W. <ott...@or...>]

Guru Kathiresan wrote:
> 
> I was mentioning about the website you have the wxcode. It will be great ,
> If you have some categorization of the code and way for automatic submission
> etc. Having a website that resembles torry.net or codeproject.com will
> greatly improve the usability of wxcode.
> Hope I explained properly this time.
> 
Yes, I understand now ;-)

It would be nice if wxCode had similar services as codeproject.com or
else. But it needs a person who does implement it and moderate the
forums etc. I don't have the time to do any of these.

The main goal of wxCode is to provide CVS access to anyone whould likes
to make code public and to provide easy access for users to this code.
But the work for the site has to be as minimal as possible simply to
allow for more time to develop code. So the first step is to automate
the component list, then to see that the feedback to the mainainer
works, that bugs and patches work and gets forwared to the maintainers,
etc. Each of this should be automatic but again I don't have the time to
do it myself.

O. Wyss

-- 
See a huge pile of work at "http://wyodesktop.sourceforge.net/"

[wxCode-users] TreeListCtrl new release

[Otto W. <ott...@or...>]

Since I tomorrow go on holiday for a week I've made a new release of the
wxTreeListCtrl component. The file release is available from the
component list at wxCode.

O. Wyss

-- 
See a huge pile of work at "http://wyodesktop.sourceforge.net/"

[wxCode-users] wxCrashPrint: New version and file release

[Otto W. <ott...@or...>]

I've added a version string to the backtrace output, and added the fatal
exception handling to the sample so you could use it as a simple
tutorial. 

I also updated the website and made a file release. Just look at the
wxCode website to the component list.

O. Wyss

-- 
See a huge pile of work at "http://wyodesktop.sourceforge.net/"

[wxCode-users] Listing any open source code for wxWidgets, Licenses

[Otto W. <ott...@or...>]

Since there is rather much code out there somewhere public available I'm
going to extend wxCode a little. wxCode accepts now components which
just point to the appropriate place on the web where the component is
located. That means a component only needs to submit a Readme which
describes it and also contains a web link. I'll adjust the
infrastructure after my holiday next week accordingly.

IMO it's quite clear that any code stored within wxCode CVS has to be
licensed or co-licensed under the wxWidgets license. Any code not
licensed this way will sooner or later be removed. If you know any such
code first contact the maintainer to solve the licensing. If it isn't
solved within a certain time, send a notice to this list. Or course any
component, which stores its code somewhere else, isn't restricted to this!

O. Wyss

-- 
See a huge pile of work at "http://wyodesktop.sourceforge.net/"

Re: [wxCode-users] Bakefiles & wxCode's components

[Otto W. <ott...@or...>]

Francesco Montorsi wrote:
> 
> > First of all each component is free to choose its own build system.
> I'm just proposing to put a bakefile in a folder like wxCode/build to
> give to the programmers of wxCode the *possibility* to use bakefile:

I've given you access rights to  wxCode/build. 

O. Wyss

-- 
See a huge pile of work at "http://wyodesktop.sourceforge.net/"

Re: [wxCode-users] Bakefiles & wxCode's components

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

Hi,

> First of all each component is free to choose its own build system.
I'm just proposing to put a bakefile in a folder like wxCode/build to
give to the programmers of wxCode the *possibility* to use bakefile:
it wouldn't be required, just an option to make "standardized" the
compilation & packaging of a wxCode's component.
Each programmer could decide to use its old build system
(tipically a makefile) or bakefile or both.


> Second it's not easy possible to create a build system for all
> components since if one doesn't build it may stop the others from
> building.
well, I did not mean to create a super-makefile/bakefile which allows
the compilation of all components with one command.
I'm just proposing to give to all the components whose mantainers approve 
this build
system the same targets in bakefile-generated makefiles: they could be

- ALL:  docs + samples + lib + tarball + others
- LIB: creates a (small) library using the sources of the component (if it 
makes sense for
          the component to be packaged in a library)
- TARBALL: creates a tar.gz archive containing the sources of the component, 
to provide
          1) the release of the component, ready to be uploaded at SF.net
          2) an easy-to-use system for the component's mantainer to provide 
the sources
              of its component to others.
- DOCS: creates the documentation for the component, if it support some sort 
of doc-generation
            (like doxygen)
- SAMPLES: builds all the samples of the component

In this way, a programmer who wants to use a component can decide if he 
wants to
use it as an external library (and thus compiling the component with the LIB 
target)
or to integrate the component's sources in its project (downloading for 
example the tarball)....

> Of course you are free to create as system which can handle a
> changing set of components. Anyway it doesn't make much sense to create
> a build system for wxCode as long as it isn't supported by wxWidgets.
such a system could be easily integrated in the future in wxWidgets build 
system
since bakefiles are quite flexible and they are used everywhere in 
wxWidgets.


> Third I don't think Bakefile is needed for anything else except the
> _main_ wxWidgets libraries. The _only_ solution is to use wx-config all
> the time since wx-config contains _every_ build information on any
> system. BTW IMO even the main libraries could be built with wx-config
> without Bakefile not to speak of all the contribs, demos, samples,
> utilities, etc.
wx-config program is wonderful but it can be used only with those systems
supporting autoconf: on win32 you cannot use wx-config (at least, not with
all compilers !).

if you see my components, you will see that in the BUILD folder, there
are always two bakefiles: wxbase.bkl and wxscript/keybinder/....

wxbase.bkl is a bakefile I modified from the original version created by
Ryan Norton and which I put at wxwiki: it allows the creation of perfectly
working win32 makefiles and the use of autoconf on platform supporting it.
Precisely, using wxbase.bkl you can produce "Makefile.in" files containing
the following CXXFLAGS:

MATHCORE_CXXFLAGS = $(__mathcore_PCH_INC) $(MCDEBUG_DEFINE) 
$(MCINCLUDE_PATHS) \
 -I../../include `wx-config --cxxflags` -Wall $(CPPFLAGS) $(CXXFLAGS)

as you see, bakefile allows without any problem the usage of "wxconfig"
(with the compilers that support it)


> Bakefile has its use for creating base make/project files for all the
> different platform but it shouldn't be used for more. Just look at the
> Makefile of treelisttest and compare it with the Makefile of wyoEditor.
> You can easily copy this Makefile and just exchange the source files and
> maybe the libraries. With the use of wx-config nothing else is needed
> while it works everywhere.
also on win32 ?
As far as I know, only the mingw compiler (& cygwin suite) supports the use
of wx-config on win32....

As you said, GCC makefiles can be easily re-used (in fact, my components
are actually using bakefile only to generate win32 makefiles) and I often
copy them just changing the source file lists, too.
Anyway, hybrid solutions can be easily supported, too: the mantainer would
be free to choose what he likes most.

Let me know,
Francesco Montorsi

Re: [wxCode-users] Bakefiles & wxCode's components

[Otto W. <ott...@or...>]

Francesco Montorsi wrote:
> 
>      since Bakefile is now the official build system of wxWidgets, I was
> wondering:

First of all each component is free to choose its own build system.

Second it's not easy possible to create a build system for all
components since if one doesn't build it may stop the others from
building. Of course you are free to create as system which can handle a
changing set of components. Anyway it doesn't make much sense to create
a build system for wxCode as long as it isn't supported by wxWidgets.

Third I don't think Bakefile is needed for anything else except the
_main_ wxWidgets libraries. The _only_ solution is to use wx-config all
the time since wx-config contains _every_ build information on any
system. BTW IMO even the main libraries could be built with wx-config
without Bakefile not to speak of all the contribs, demos, samples,
utilities, etc.

Bakefile has its use for creating base make/project files for all the
different platform but it shouldn't be used for more. Just look at the
Makefile of treelisttest and compare it with the Makefile of wyoEditor.
You can easily copy this Makefile and just exchange the source files and
maybe the libraries. With the use of wx-config nothing else is needed
while it works everywhere.

O. Wyss

-- 
See a huge pile of work at "http://wyodesktop.sourceforge.net/"

Re: [wxCode-users] Bakefiles & wxCode's components

[Mike W. <mik...@nt...>]

On Saturday 02 October 2004 5:36 pm, Francesco Montorsi wrote:
>      since Bakefile is now the official build system of wxWidgets, I
> was wondering:
> it should be possible to put in the wxCode folder a dir like "build"
> containing some
> bakefiles common to all the components, making easier for the
> programmer both the packaging & the cross-compilation.
>
> What do you think about it ?

Yes I think the same. Each component could have a small bakefile which 
includes a central wxCode bakefile which does all the work. Rather like 
in wxWidgets each contrib has a small bakefile which includes 
wxWidget's 'build/bakefiles/common_contrib.bkl'.

Regards,
Mike

[wxCode-users] Bakefiles & wxCode's components

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

Hi,
     since Bakefile is now the official build system of wxWidgets, I was
wondering:
it should be possible to put in the wxCode folder a dir like "build"
containing some
bakefiles common to all the components, making easier for the programmer
both the packaging & the cross-compilation.

It could be a easy to make more uniform also the compilation process of
those
programmers who want to try out several components.

With some tricks, we could add the "dist", "docs", "tarball" targets or what
else to *all*
components (with a very small effort for the mantainer of each
component...).

What do you think about it ?

Thanks,
FM

[wxCode-users] Re: [wxGuide-users] wyoeditor

[Otto W. <ott...@or...>]

> Jonas  () has submitted this feedback
> 
Thanks, this helps me to concentrate on the most important issues if I'm able.

> The editor works well in Windows. I use it all the time and am happy I found it. In Linux 
> however it has a tendency to crash and I regretfully decided not to use it. I have been 
> looking for an editor that behaves the same in windows and Linux for a long time ... :(
> 
I still use it on Linux because I haven't found anything better :-( .
BTW that was my first reason to create wyoEditor. Now it's also a
marketing item to show others how to write good applications.

Crashes in Linux are while most pressing unfortunately also something I
can't do much. Most (if not all) of these crashes are rooted within
wxWidgets and/or GTK+. All I can try is to see if the crashes are within
my sources or try to locate the problems within wxWidgets myself.
Saddening even if discover them they aren't fixed within wxWidgets, just
look at the patches I still have to put up. And most saddening if I only
can attribute it to wxWidgets, my bug reports are simply closed (see
"http://sourceforge.net/tracker/index.php?func=detail&aid=998555&group_id=9863&atid=109863").
All I can do is hope that any crash is fixed by other means and leave it
to the user to submit bug reports. Very sorry :-((

> When I whent back to see if a newer version would solve the problem I found that the 
> dependencies where to something that would force me to manually upgrade some stuff
> and NO NOTE about that change in the release.
> 
I'm hard pressed to just look for the most important issue although I
spend _all_ my spare time for development (haven't played any doom for
years!). Caring for changelog doesn't have by far enough high priority,
you either have to look at the release statements at
"http://freshmeat.net/projects/wyoeditor/" or walk through CVS. Of
course anyone else is welcomed to take over this task.

> Having control over the dependencies and installation is a thing the open-source still 
> fail in. This makes me sad since many projects are so good. I know there are many 
> people that thinks it\'s all right to download source and manually resolve dependencies, 
> build, install and configure software. But me and the many others that have a life and 
> whant to USE lots of good software will eventually fall back. This leaves many of the 
> projects only suitable to entusiasts. I see this as a great loss to us all....
> 
I see your point but sorry I've absolute _no_ time to care myself. I
also prefer to just USE instead of DEVELOP good software. I still hope
and do everything I can so we all are able to USE in a not too distant future.

> I wonder how many good projects die because of this lack shutting out a LARGE user-base
> ... and then similar projects are started again ... and fails again. Eventually no one thinks 
> the idea is good. But it is, they just fail to complete the delivery part, and decay is 
> introduced..
> 
As long as users don't take over their share of work this situation
won't change! See that I get much more time to care for all the issues a
normal user shouldn't be confronted. To solve exactly this issue I've
created the wyoDesktop project "http://wyodesktop.sourceforge.net/" but
without your help, you have to wait some decades until you can USE it.

Why don't you start an OpenSource fan club which does some lobbying
- in newspapers and public forums to spread the news about wyoDesktop
- to attract others (developers and users) to participate as much as
they can
- to attract sponsors (companies and politicians) to solve resource problems
- at universities to enhance and enforce the wxGuide guidelines
- ...
so there is finally enough man power to take care for all the
outstanding issues.

> ... Good editor, barely usefull project.
> 
Thanks, what do you with "barely useful project".

O. Wyss

-- 
See a huge pile of work at "http://wyodesktop.sourceforge.net/"

Re: [wxCode-users] Component list updates

[Otto W. <ott...@or...>]

Joseph Blough wrote:
> 
> If the page is  dynamically generated from the readme files, then it might
> be best to not access CVS in the script (for speed concerns).  For that
> we'd probably need a local checkout of the CVS components branch.  How
> 
I've no objections against a checkout with a cron job. Unfortunately
cron doesn't work all the time i.e. I've daily cron job which should
update the components websites (all the index.html) but they aren't.
Didn't you just now update shortcutpanel? Just check within 24h if it's
still old. If it wer possible to trigger an update via web than a
maintainer could force it when he changed it. If we just checkout the
readme's the space won't be a problem.

The released files (downloads) aren't accessable as the SF staff told me
but we could add a release date or version to the readme files.

I'd prefer to checkout all the readme files and generate the page
dynamically. The checkout could be done with cron or manually.

> that it's a cvs checkout/update which could hopefully be automated as
> well.
> 
Yes it is but only if cron is working. :-(

O. Wyss

-- 
See a huge pile of work at "http://wyodesktop.sourceforge.net/"

Re: [wxCode-users] Component list updates

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

Hi,

> The component list is currently just hand made even if it's complist.php
> (see CVS website). My idea is it should be build up from all the readme
> files in CVS. That way any maintainer just can update his readme and the
> component list picks up the information immediately.
if someone is going to make a PHP to update component list, I would like to
suggest a little feature about the readme:
since I'm mainly a win32 user, I like to have readmes called "readme.txt"
and not only "readme"... this is why I made this
change in all my components submitted to wxCode.

It should not be too difficult to search for Readme and Readme.txt as well
when generating the component list... :-)

Francesco Montorsi

Re: [wxCode-users] Component list updates

[Joseph B. <jb...@um...>]

If the page is  dynamically generated from the readme files, then it might
be best to not access CVS in the script (for speed concerns).  For that
we'd probably need a local checkout of the CVS components branch.  How
feasible is it to have a copy checked out?  Does SourceForge allow for
that much space?  The file release information can't be pulled from CVS.
Are the file releses held in a directory heirarchy so that we could figure
out if a component has a release?  Or is parsing through the releases page
look like the safest way?  Even if it isn't possible to make the page
dynamic (without slowing down the end-user experience too much), I don't
think that a 24 hour delay to generate a static page via a cron job would
be too bad.  At least it would take some of the burden off of you.

Aside from generating the comlist.php page, how do the pages currently
under each components "website" directory end up in the live
http://wxcode.sourceforge.net/components/ComponentX/ directory where the
user can see them?  Since it's possible to browse to
http://wxcode.sourceforge.net/components/ComponentX/CVS/, I'm guessing
that it's a cvs checkout/update which could hopefully be automated as
well.

Re: [wxCode-users] Component list updates

[Otto W. <ott...@or...>]

Joseph Blough wrote:
> 
> Is there anything that we need to do to trigger changes to the information
> on the component list page (http://wxcode.sourceforge.net/complist.php)?
> I've noticed that a few of the components do have file releases although
> the page says that they do not, and the same with "Docs".  If this isn't
> an automated process, maybe it could be with a nightly cron job scraping
> the releases page and looking through CVS for index.html files that don't
> match the template index.html for Docs.  Infrastructure maintenance is
> never the most fulfilling of tasks, but it's just an idea.
> 
The component list is currently just hand made even if it's complist.php
(see CVS website). My idea is it should be build up from all the readme
files in CVS. That way any maintainer just can update his readme and the
component list picks up the information immediately. 

If you know enough PHP you're welcome to code looping through all the
component an retrieve the informations from the readme's.

O. Wyss

-- 
See a huge pile of work at "http://wyodesktop.sourceforge.net/"

[wxCode-users] Component list updates

[Joseph B. <jb...@um...>]

Is there anything that we need to do to trigger changes to the information
on the component list page (http://wxcode.sourceforge.net/complist.php)?
I've noticed that a few of the components do have file releases although
the page says that they do not, and the same with "Docs".  If this isn't
an automated process, maybe it could be with a nightly cron job scraping
the releases page and looking through CVS for index.html files that don't
match the template index.html for Docs.  Infrastructure maintenance is
never the most fulfilling of tasks, but it's just an idea.

[wxCode-users] ShortcutPanel: Application for code submission

[<sub...@wx...>]

Joe Blough (jb...@um...) wants to submit a component

Maintainer: Joe Blough (jblough)
Component:  ShortcutPanel
Subdir:     ShortcutPanel
Parts:      DS
More infos: 
wxWidgets:  2.4.0

Description:
Originally written by Jonatan Magnusson of Phoenix Data, this component provides an old-style \"Outlook-like\" shortcut bar within a wxPanel derived class.

Re: [wxCode-users] keybinder: Application for code submission

[Otto W. <ott...@or...>]

sub...@wx... wrote:
> 
> Francesco Montorsi (fr...@us...) wants to submit a component
> 
> Maintainer: Francesco Montorsi (frm)
> Component:  keybinder
> Subdir:     keybinder
> Parts:      DS
> More infos:
> wxWidgets:  2.4.x;2.5.x
> 
Added.

O. Wyss

-- 
See a huge pile of work at "http://wyodesktop.sourceforge.net/"

[wxCode-users] keybinder: Application for code submission

[<sub...@wx...>]

Francesco Montorsi (fr...@us...) wants to submit a component

Maintainer: Francesco Montorsi (frm)
Component:  keybinder
Subdir:     keybinder
Parts:      DS
More infos: 
wxWidgets:  2.4.x;2.5.x

Description:
A generic system to bind one or more keyshortcuts to the commands you want (menu commands or whatever you like).

A pre-built panel and a complete system for viewing/remove/add/edit command shortcuts is included.

Integrates with your applications with few modifications and allows the users to customize all the commands he wants, bypassing the limitation of a single keybind to each command.

Re: [wxCode-users] Deleting Root Item will crash tree

[Otto W. <ott...@or...>]

> Ray Gilbert (ra...@sc...) wants to give feedback for component: treelistctrl
> 
> If you treelistctrl->Delete(rootItem), it should be equivalent to DeleteAllItems(), but Delete(item) does not cleanup m_anchor, if item is root
> 
Since the root item is added by a "AddRoot" and not by "AppendItem" IMO
it shouldn't be possible to delete the root item with "Delete". IMO it's
better to return an assert message. Also a treelist without a root item
doesn't make sense and might lead to lots of special cases.

It seems wxTreeCtrl allows to delete the root item which is IMO wrong. Opinions?

It would make sense to rename "AppendItem" to "Append" or "Delete" to
"DeleteItem" but I'll only change that if wxTreeCtrl is changed accordingly.

O. Wyss

-- 
See a huge pile of work at "http://wyodesktop.sourceforge.net/"

[wxCode-users] Deleting Root Item will crash tree

[<fee...@wx...>]

Ray Gilbert (ra...@sc...) wants to give feedback for component: treelistctrl


If you treelistctrl->Delete(rootItem), it should be equivalent to DeleteAllItems(), but Delete(item) does not cleanup m_anchor, if item is root

Re: [wxCode-users] wxBetterDialog: Application for code submission

[Otto W. <ott...@or...>]

sub...@wx... wrote:
> 
> Brian Allen Vanderburg II (bri...@ya...) wants to submit a component
> 
> Maintainer: Brian Allen Vanderburg II (bavander)
> Component:  wxBetterDialog
> Subdir:     wxBetterDialog
> Parts:
> More infos:
> wxWidgets:  2.4.2
> 
> Description:
> This is just a collection of better dialogs for wxWidgets.  First is
> 
> wxBetterColourDialog which works like wxColourDialog but is much better than (in my opinion) even the windows color chooses.  There is also a wxBetterGradientDialog which allows easy editing of gradients.
> 
> At present only the source and header files are included.
> 
Added with subdir wxbetterdialog (only lower cases). BTW your
sourceforge account is "brianvanderburg", isn't it.

O. Wyss

-- 
See a huge pile of work at "http://wyodesktop.sourceforge.net/"

[wxCode-users] wxBetterDialog: Application for code submission

[<sub...@wx...>]

Brian Allen Vanderburg II (bri...@ya...) wants to submit a component

Maintainer: Brian Allen Vanderburg II (bavander)
Component:  wxBetterDialog
Subdir:     wxBetterDialog
Parts:      
More infos: 
wxWidgets:  2.4.2

Description:
This is just a collection of better dialogs for wxWidgets.  First is

wxBetterColourDialog which works like wxColourDialog but is much better than (in my opinion) even the windows color chooses.  There is also a wxBetterGradientDialog which allows easy editing of gradients.



At present only the source and header files are included.

Re: [wxCode-users] Component packaging

[Otto W. <ott...@or...>]

>        I would like to ask you an advice about component packaging: I
> have almost completed some components (wxscript, wxxml2 and
> paletteframe) and I would like to allow the programmer who wants to
> use them to easily add to his projects... how could I do this:
> 
>  - should I config my component as a separated very very small library
> (useful when the component has many source files and maybe some
> complicated compile-settings...) ?
> 
> - should I distribute my component as an extension of wxWidgets
> library; that is, distributing modified wxWidgets makefiles to make my
> component part of the final library (useful for my paletteframe
> component, for example, which
> has the same wxWidgets folder structure [common, generic, msw, gtk,
> x11 ...] and thus different compile-setting for
> different operating systems...) ?
> 
> - should I just distribute the sources and tell the programmer to
> compile & link them together with his source files ?
> 
I haven't found a good way to integrate my components into wxWidgets so
I just distribute sources and leave it to the user how to integrate them.

Look once at treelistctrl. Only a single source and include file are
distributed so it's rather easy for a user. I use it in my wyoEditor
where I integrate it via an environment variable $WXCODE which points to
the wxCode/components directory.

The best is probably if you build your sample like an application
outside of wxCode so it's easy for a user to see how to do it. I've just
upgraded the treelistctrl sample to use the same structure.

O. Wyss

-- 
See a huge pile of work at "http://wyodesktop.sourceforge.net/"

[wxCode-users] Component packaging

[f18m_cpp271828 <f18...@ya...>]

Hi,
       I would like to ask you an advice about component packaging: I =
have almost completed some components (wxscript, wxxml2 and =
paletteframe) and I would like to allow the programmer who wants to use =
them to easily add to his projects... how could I do this:
=20
 - should I config my component as a separated very very small library =
(useful when the component has many source files and maybe some =
complicated compile-settings...) ?

- should I distribute my component as an extension of wxWidgets library; =
that is, distributing modified wxWidgets makefiles to make my component =
part of the final library (useful for my paletteframe component, for =
example, which
has the same wxWidgets folder structure [common, generic, msw, gtk, x11 =
...] and thus different compile-setting for
different operating systems...) ?

- should I just distribute the sources and tell the programmer to =
compile & link them together with his source files ?

Let me know what you think,
Francesco Montorsi