wxcode-users — Submission, Questions, Information

[wxCode-users] Cvs login fail

[<die...@fr...>]

Hi,

Sorry, I don't understand why I cant login to the cvs:

cvs -z3 -d :pserver:ano...@cv...:/cvsroot/wxCode login
Logging in to :pserver:ano...@cv...:2401:/cvsroot/wxCode
cvs [login aborted]: authorization failed: server cvs.sourceforge.net 
rejected access to /cvsroot/wxCode for user anonymous

Thanks,
Didier

Re: [wxCode-users] Searching help for a new useful wxWidgets class

[Francesco <fr...@ho...>]

Thanks both to Julian and Otto.

>Of course you may consider to put up your project on wxCode to attract
>others. But unless it's at least somehow working on one port it won't
>help either. The best way is always to make a sample so interested
>people can just try it out.
I already have a sample working perfectly on Win32 but with two problems under wxGTK.... 

I have contacted Mark McCormack as Julian has suggested me; I hope 
he will be able to help me.

Thank you very much indeed,
Francesco


----- Original Message ----- 
From: "Julian Smart" <ju...@an...>
To: <wxc...@li...>
Sent: Monday, May 03, 2004 10:40 PM
Subject: Re: [wxCode-users] Searching help for a new useful wxWidgets class


> Hi Francesco,
> 
> It's worth talking to "Mark McCormack" <mar...@vi...>
> who is working on a docking window system called wxExtended
> that aims to replace FL. He's quite far advanced with it and plans
> to host it on SF (I suggested wxCode but it may be too
> late to change his decision on that).
> 
> Regards,
> 
> Julian
> 
> At 20:58 02/05/2004, you wrote:
> >Hi;
> >     I'm not a wxCode programmer so I don't know exactly if I can post 
> > such a message in this ML..... hope you will forgive
> >me if I cannot...
> >I sent this message also in the wx-users ML but I didn't find any help so 
> >I try to ask your support.
> >
> >I think this is an issue which will be quite interesting to all the users 
> >of the FL library and to all the programmers
> >looking for a cross-platform advanced wxWindows-compatible toolbar.
> >
> >The need for such a class is due to the fact that the wxToolWindow class 
> >used in FL library works on Win32 only, it is quite messy,
> >it's missing some features (regarding focus, mainly) and it can be used 
> >only with the FL library which is still unstable...
> >
> >I and another developer are working on a similar class, wxPaletteFrame 
> >which has the following features:
> >   1) the ability to be activated/deactivated when the main frame
> >      activation state changes (wxMSW only)
> >   2) the ability to contain any type of children, and to use
> >      wxSizers to layout them; this allows the creation of
> >      "advanced toolbars" (e.g. like MSOffice's ones)
> >   3) the ability to draw any type of wxMiniButton in its caption
> >      area (standard minibuttons are already provided)
> >   4) the ability to be rolled/unrolled (maybe using wxCollapseBox);
> >      useful for big wxPaletteFrame windows
> >   5) the ability to show a context menu, when right-clicked in the
> >      caption bar, to allow the user to show/hide a specific palette
> >   6) the ability to save/load the layout of the wxPaletteFrames
> >      in the given wxConfig object
> >   7) it can be used without almost no modifications in your program
> >   8) the cross-platformness (wxMSW and wxGTK)
> >
> >This last point is one of the most important and it is not completed yet: 
> >we are trying to make it work correctly under GTK but we
> >are experiencing two big problems connected with our not-so-deep knowledge 
> >of the GTK libraries.
> >This is why I'm mailing this message: I'm searching someone to help us to 
> >complete the class under GTK. Then, when it will be
> >completed, I will be happy to release it to the entire wxWidgets community 
> >with the relative samples & screenshots.
> >
> >So; if you know C++, you have experience with GTK and you are interested 
> >in such a class, please reply to me (at
> >fr...@us...) and I'll give you all the details.
> >
> >Thank you all,
> >Francesco Montorsi
> >
> >
> >
> >
> >-------------------------------------------------------
> >This SF.Net email is sponsored by: Oracle 10g
> >Get certified on the hottest thing ever to hit the market... Oracle 10g.
> >Take an Oracle 10g class now, and we'll give you the exam FREE.
> >http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> >_______________________________________________
> >wxCode-users mailing list
> >wxC...@li...
> >https://lists.sourceforge.net/lists/listinfo/wxcode-users
> 
> =========================================================================
> Julian Smart                           ju...@an...
> 3F1, 28 Gillespie Crescent,            www.anthemion.co.uk
> Edinburgh, Midlothian, U.K., EH10 4HU  +44 (0)131 229 5306
> StoryLines:   story structuring        www.writerscafe.co.uk
> HelpBlocks:   HTML help authoring      www.helpblocks.com
> DialogBlocks: cross-platform dialogs   www.anthemion.co.uk/dialogblocks
> ========================================================================= 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 10g. 
> Take an Oracle 10g class now, and we'll give you the exam FREE. 
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> wxCode-users mailing list
> wxC...@li...
> https://lists.sourceforge.net/lists/listinfo/wxcode-users
> 

Re: [wxCode-users] Searching help for a new useful wxWidgets class

[Julian S. <ju...@an...>]

Hi Francesco,

It's worth talking to "Mark McCormack" <mar...@vi...>
who is working on a docking window system called wxExtended
that aims to replace FL. He's quite far advanced with it and plans
to host it on SF (I suggested wxCode but it may be too
late to change his decision on that).

Regards,

Julian

At 20:58 02/05/2004, you wrote:
>Hi;
>     I'm not a wxCode programmer so I don't know exactly if I can post 
> such a message in this ML..... hope you will forgive
>me if I cannot...
>I sent this message also in the wx-users ML but I didn't find any help so 
>I try to ask your support.
>
>I think this is an issue which will be quite interesting to all the users 
>of the FL library and to all the programmers
>looking for a cross-platform advanced wxWindows-compatible toolbar.
>
>The need for such a class is due to the fact that the wxToolWindow class 
>used in FL library works on Win32 only, it is quite messy,
>it's missing some features (regarding focus, mainly) and it can be used 
>only with the FL library which is still unstable...
>
>I and another developer are working on a similar class, wxPaletteFrame 
>which has the following features:
>   1) the ability to be activated/deactivated when the main frame
>      activation state changes (wxMSW only)
>   2) the ability to contain any type of children, and to use
>      wxSizers to layout them; this allows the creation of
>      "advanced toolbars" (e.g. like MSOffice's ones)
>   3) the ability to draw any type of wxMiniButton in its caption
>      area (standard minibuttons are already provided)
>   4) the ability to be rolled/unrolled (maybe using wxCollapseBox);
>      useful for big wxPaletteFrame windows
>   5) the ability to show a context menu, when right-clicked in the
>      caption bar, to allow the user to show/hide a specific palette
>   6) the ability to save/load the layout of the wxPaletteFrames
>      in the given wxConfig object
>   7) it can be used without almost no modifications in your program
>   8) the cross-platformness (wxMSW and wxGTK)
>
>This last point is one of the most important and it is not completed yet: 
>we are trying to make it work correctly under GTK but we
>are experiencing two big problems connected with our not-so-deep knowledge 
>of the GTK libraries.
>This is why I'm mailing this message: I'm searching someone to help us to 
>complete the class under GTK. Then, when it will be
>completed, I will be happy to release it to the entire wxWidgets community 
>with the relative samples & screenshots.
>
>So; if you know C++, you have experience with GTK and you are interested 
>in such a class, please reply to me (at
>fr...@us...) and I'll give you all the details.
>
>Thank you all,
>Francesco Montorsi
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: Oracle 10g
>Get certified on the hottest thing ever to hit the market... Oracle 10g.
>Take an Oracle 10g class now, and we'll give you the exam FREE.
>http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
>_______________________________________________
>wxCode-users mailing list
>wxC...@li...
>https://lists.sourceforge.net/lists/listinfo/wxcode-users

=========================================================================
Julian Smart                           ju...@an...
3F1, 28 Gillespie Crescent,            www.anthemion.co.uk
Edinburgh, Midlothian, U.K., EH10 4HU  +44 (0)131 229 5306
StoryLines:   story structuring        www.writerscafe.co.uk
HelpBlocks:   HTML help authoring      www.helpblocks.com
DialogBlocks: cross-platform dialogs   www.anthemion.co.uk/dialogblocks
========================================================================= 

Re: [wxCode-users] Searching help for a new useful wxWidgets class

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

Francesco wrote:
> 
>     I'm not a wxCode programmer so I don't know exactly if I can post such
> a message in this ML..... hope you will forgive me if I cannot...
> I sent this message also in the wx-users ML but I didn't find any help so I
> try to ask your support.
> 
You can post here but I doubt if you get more echo than on wx-users.
Mostly wxCode maintainers are subscribed here and they all are probably
pressed with enough of their own work. And most probably they are
subscribed to wx-users as well.

Of course you may consider to put up your project on wxCode to attract
others. But unless it's at least somehow working on one port it won't
help either. The best way is always to make a sample so interested
people can just try it out.

Another way to get help is to try to do as much as you can yourself and
just ask about the problem where you got stuck in wx-users. If someone
knows the answer it's surely given.

O. Wyss

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

[wxCode-users] Searching help for a new useful wxWidgets class

[Francesco <fr...@ho...>]

Hi;
    I'm not a wxCode programmer so I don't know exactly if I can post such a message in this ML..... hope you will forgive
me if I cannot...
I sent this message also in the wx-users ML but I didn't find any help so I try to ask your support.

I think this is an issue which will be quite interesting to all the users of the FL library and to all the programmers
looking for a cross-platform advanced wxWindows-compatible toolbar.

The need for such a class is due to the fact that the wxToolWindow class used in FL library works on Win32 only, it is quite messy,
it's missing some features (regarding focus, mainly) and it can be used only with the FL library which is still unstable...

I and another developer are working on a similar class, wxPaletteFrame which has the following features:
  1) the ability to be activated/deactivated when the main frame
     activation state changes (wxMSW only)
  2) the ability to contain any type of children, and to use
     wxSizers to layout them; this allows the creation of
     "advanced toolbars" (e.g. like MSOffice's ones)
  3) the ability to draw any type of wxMiniButton in its caption
     area (standard minibuttons are already provided)
  4) the ability to be rolled/unrolled (maybe using wxCollapseBox);
     useful for big wxPaletteFrame windows
  5) the ability to show a context menu, when right-clicked in the
     caption bar, to allow the user to show/hide a specific palette
  6) the ability to save/load the layout of the wxPaletteFrames
     in the given wxConfig object
  7) it can be used without almost no modifications in your program
  8) the cross-platformness (wxMSW and wxGTK)

This last point is one of the most important and it is not completed yet: we are trying to make it work correctly under GTK but we
are experiencing two big problems connected with our not-so-deep knowledge of the GTK libraries.
This is why I'm mailing this message: I'm searching someone to help us to complete the class under GTK. Then, when it will be
completed, I will be happy to release it to the entire wxWidgets community with the relative samples & screenshots.

So; if you know C++, you have experience with GTK and you are interested in such a class, please reply to me (at
fr...@us...) and I'll give you all the details.

Thank you all,
Francesco Montorsi

Re: [wxCode-users] Updated website

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

On Saturday 01 May 2004 8:31 am, Otto Wyss wrote:
> Does anyone know how this script can be started through a cron job on
> sf.net?

Hi Otto,

'crontab -e' should bring up an editor where you can type in your 
crontab entries. Have a look at crontab(5) for information about the 
layout of the entries.

I noticed that for gzstream it says 'no' under 'Docs'. So to make that 
'yes', I just need to create a 'website' sub-directory under 'gzstream' 
in the CVS and put an 'index.html' in there. Is that right?

Thanks,
Mike

[wxCode-users] Building wxCode components within wxWidgets

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

I'm still looking for a good way how to integrate wxCode components
within wxWidgets. Currently it seems best if any component is extracted
into "wxWidgets/contrib/components" and build from there.

Mike Wetherell's approach to build gzstream within wxWidgets involves
building a "wx...gzstream.lib". While this might be workable for
components like gzstream IMO it's not very good for components like
hyperlink. Are there better solutions? Is it possible to build a single
components lib which contains a various amount of components? Or is it
better to just use the source files directly in such a case?

O. Wyss

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

Re: [wxCode-users] Re: Building wxCode components

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

Mike Wetherell wrote:
> 
> There are instructions on generating the makefiles in
> gzstream/install.txt. Though, rather than put it on the wxCode web
> page, it might be a better idea to ask Vaclav how he would recommend
> using bakefile for wxCode components.
> 
Have you tried to add a link within the Readme which directly links to
the install.txt, i.e. "../install.txt?view=markup"? Mabe the "../" isn't
needed. It would be nice to know if it works.

O. Wyss

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

[wxCode-users] Updated website

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

I've updated the wxCode website to be hopefully easier usable. Have a
look especially at the new component list. Each component has a website
containing at least a dummy index.html. It allows to add any
documentation to a component, see the treelistctrl.

I update the website directly through a bash script like

  cvs chechout -d treelistctrl wxCode/components/treelistctrl/website

Does anyone know how this script can be started through a cron job on sf.net?

O. Wyss

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

Re: [wxCode-users] Re: Building wxCode components

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

On Friday 30 April 2004 10:02 pm, Otto Wyss wrote:
> I don't like to copy but you are free to to do what you want.

Ok, thanks.

> It would be nice to have Backfile generate all the make files. So
> best if you make a description (understandable by a user) how to
> handle it correctly, then anyone can decide for himself if he wants
> to copy. I'll put your description on the wxCode web page.

There are instructions on generating the makefiles in 
gzstream/install.txt. Though, rather than put it on the wxCode web 
page, it might be a better idea to ask Vaclav how he would recommend 
using bakefile for wxCode components.

> BTW how far did you come with moving everything to gzstreams?

I have just done it, there didn't seem to be any problems. Thanks very 
much for your help.

Mike

Re: [wxCode-users] Re: Building wxCode components

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

Mike Wetherell wrote:
> 
> So what I'd suggest is that, instead of using these environment
> variables, the components be put directly into the wxWidgets tree
> rather than linked.
> 
> So for example, a CVS user would checkout wxCode then move the
> 'components' subdirectly into wxWidgets/contrib. I believe that cvs
> would still work correctly for the moved components subdirectory, and
> also when using cvs for wxWidgets, it would ignore the wxCode stuff.
> 
I don't like to copy but you are free to to do what you want. It might
be possible to checkout directly into wxWidgets/contrib but I think
WinCVS won't be able to separate wxWidgets and wxCode projects. On
Windows you probably have to make sure you don't copy the CVS directories.

> The reason I suggest this is that:
> 1. wxWidgets' bakefiles can be run 'as is' to generate makefiles for
> wxCode if we do this.
> 2. Not all filesystem have links.
> 3. Not all make programs support variables (though I guess those ones
> could be avoided).
> 
It would be nice to have Backfile generate all the make files. So best
if you make a description (understandable by a user) how to handle it
correctly, then anyone can decide for himself if he wants to copy. I'll
put your description on the wxCode web page.

> What do you think?
> 
I prefer wxWidgets/contrib/components/... . As much as I understand this
doesn't need any changes in wxCode. 

BTW how far did you come with moving everything to gzstreams?

Otti

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

[wxCode-users] Re: Building wxCode components

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

On Thursday 25 March 2004 4:54 pm, Otto Wyss wrote:
> Code submitted to wxCode has a problem when build and linking with
> wxWidgets. Relative path can't be used. Therefore I suggest the use
> of environment variables for this:
>
> - $(WXSTABLE): Points to the stable released wxWidgets directory
> (currently 2.4.2)
> - $(WXTEST): Points to the devel released wxWidgets directory
> (currently 2.5.1)
> - $(WXDEVEL): Points to the devel wxWidgets directory (CVS HEAD)
>
> If we can agree on the names of these variables I suggest that anyone
> starts using them. I also suggest that any code within wxWidgets
> which doesn't belong to the core starts using them as well. This
> mostly involves any code in contrib, sample, utils, etc.
>
> Standardizing on environment variables means code can much easier be
> moved from one place to the other.

Hi Otto,

As I understand it, the current idea is for 
wxWidgets/contrib/components to be a link to wxCode/components. 
However, like you say, that means that reverse relative paths don't 
work.

So what I'd suggest is that, instead of using these environment 
variables, the components be put directly into the wxWidgets tree 
rather than linked.

So for example, a CVS user would checkout wxCode then move the 
'components' subdirectly into wxWidgets/contrib. I believe that cvs 
would still work correctly for the moved components subdirectory, and 
also when using cvs for wxWidgets, it would ignore the wxCode stuff.

The reason I suggest this is that:
1. wxWidgets' bakefiles can be run 'as is' to generate makefiles for 
wxCode if we do this.
2. Not all filesystem have links.
3. Not all make programs support variables (though I guess those ones 
could be avoided).

Another suggestion, is that instead of installing the components under 
wxWidgets/contrib/components, how about installing them in 
wxWidgets/wxcode, just to make the paths a bit shorter. Or would the 
renaming be confusing? The only change that's need to make that work 
with wxWidgets' bulid system is a small change to configure.in, so I 
could ask if this would be acceptable on wx-dev.

Anyway, I've tried both these idea out, so they work ok.

What do you think?
Mike

[wxCode-users] Website access for components

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

I've though again about the web site access for components. Since all
updates go through CVS this can be accomplished rather easy. Therefore
each component should have a directory "website" containing at least a
file "index.html". This page is just a place holder and can be changed
to what ever the maintainer likes. The idea behind this website is that
any additional info are located in the same place as the component
itself. Of course it may contain any links to other locations but do it
only if there isn't any other way.

The update of the website is done directly from the CVS but currently
only manually. If you want to have it updated give me a mail. I'd be
nice if this can be done daily by a cron job on sourceforge.net. Can
anyone say me how I have to do it?

O. Wyss

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

[wxCode-users] Re: Release

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

Actually, what I was wondering about was packaging the sample up with the
libraries, dictionaries, and data files needed to demo the wxSpellChecker
component.  So I think that I had misunderstood the releases section.

Thank you for access to the releases section.  I'll hopefully have the
configuration code complete enough to have a "stable" release.

Re: [wxCode-users] Release

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

Joseph Blough wrote:
> 
> I'd like to post a release of the wxSpellChecker demo with the dictionary
> support files (~2.6 MB).  Is this possible at this time?
>
I'v given you all release tech rights, so you should be able to make
file releases. First create a single file release of the package
"components" with your module name ("wxspellchecker"). Then create a

  <componentname>.tar.gz ("wxspellchecker.tar.gz")

and upload it. The file name should currently match exactly with
component name (plus ".tar.gz") since I intend to use this name in the
component list. The name of the file release doesn't have this
restriction but I'd would make it similar (i.e. "wxSpellChecker"). In
the future if possible the file name might be as

  <componentname><anything>.tar.gz ("wxspellchecker.12.3-456.tar.gz")

but this has to wait until I'm sure it works. If you aren't able to
build a file release ask here for help.

wxCode may not store binaries at least no binaries from the submitted
code. The reason is any code should be in a state where it successfully
builds. Also downloads should be within reasonable limits. Therefore a
package should only contain sources. That's what the users expect.

Your dictionaries are a little different but why do you want them do be
included? Doesn't a usual distributen have these dicts in the choosen
language? Or isn't it possible to get the dicts by other means?

I've already added a column "More" which will be just a link to a your
web page where you can put up everything. Just tell me its URL.

O. Wyss

-- 
See "http://freshmeat.net/projects/wxguide" for application design
See "http://freshmeat.net/projects/wxguide-editor" for a nice editor

[wxCode-users] wxGzipInput/OutputStream: Application for code submission

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

Michael Wetherell (mik...@nt...) wants to submit a component

Maintainer: Michael Wetherell (chiclero)
Component: wxGzipInput/OutputStream
Subdir: wxGzipInput/OutputStream
wxWidgets: 2.5.x

Description:
Hi Otto,



Please can I move the wxGzipXXXXStream classes from

wxWidgets to here?



The builtin zlib library will be upgraded soon, and

then wxZlibXXXXStreams will be able to handle gzip\'s

by themselves.



But the wxGzipXXXXStream does have some features that

wxZlibXXXXStream will lack, and so I would like to make

them available here in case anyone needs it.



Mike

[wxCode-users] Release

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

I'd like to post a release of the wxSpellChecker demo with the dictionary
support files (~2.6 MB).  Is this possible at this time?

Thanks!

[wxCode-users] Guidelines - project build files

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

It's rather straight forward that source code, header files, and such go
into the CVS repository and (non-binary) releases, but is there a
preference for the build "instructions"?  I'm currently posting msp files
for Win32 and Linux which are the project files for MinGWStudio.  Over
time I also plan to add Visual C++ dsp files.  Unfortunately, I'm not as
familiar with the autogen and configure tools to be able to easily post
those.  I could always post a Makefile exported from MinGWStudio if that
would be acceptable.

wxWidgets itself seems to include an elaborate set of makefiles,
bakefiles, dsp's, and more.  Is there a wxCode guideline for what "build
instruction" files should be included?

Thank you.

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

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

sub...@wx... wrote:
> 
> Joe Blough (jb...@um...) wants to submit a component
> Component name:    wxSpellChecker
> Subdir name:       wxSpellChecker

Submission approved, the component directory is in CVS, you should be
able to access it. 

O. Wyss

-- 
See "http://freshmeat.net/projects/wxguide" for application design
See "http://freshmeat.net/projects/wxguide-editor" for a nice editor

[wxCode-users] wxSpellChecker: Application for code submission

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

Joe Blough (jb...@um...) wants to submit a component
Component name:    wxSpellChecker
Subdir name:       wxSpellChecker
SF user account:   jb...@us...
wxWidgets version: 2.4.2

wxSpellChecker is an library that provides an API to use various spell checker engines through wxWidgets classes or a C interface.  The developer should have flexibility in the dialog design (using XML resources) and the spell checking interface (only Aspell and Myspell are supported at this time).  For maximum control, developers can derive dialog classes from wxSpellCheckDialogInterface and create more customized dialogs.  Non-dialog based interfaces can be created by deriving from the wxSpellCheckUserInterface directly.  Also support can be added for more spell check engines as needed using the wxSpellCheckEngineInterface base class.

[wxCode-users] test: Application for code submission

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

wyo (test@nowhere) wants to submit the component: testComponent name:    test
Subdir name:       test
SF user account:   te...@us...
wxWidgets version: 1.2.3

Test

[wxCode-users] wxSheet: Application for code submission

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

John Labenski () wants to delete a submission.Component name: wxSheet
Component directory: wxCode/components/wxSheet
SF user ac...@us...

wxSheet is a spreadsheet type grid widget for the wxWidgets GUI library. The wxSheet code is based on the wxWidget\'s wxGrid class and is, for the most part, a complete rewrite, almost every function has been tweaked. It is not backwards compatible, but operates and is logically similiar. Many of the functions have the same names and you can expect them to perform a similiar task, but the parameters may be different. The reason for creating a completely separate grid implementation is to allow far more control over the different aspects of the operation either though subclassing or intercepting events.