wxcode-users — Submission, Questions, Information

Re: [wxCode-users] About wxpdfdoc

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

Hi,

> This lead me to find some problems.
> 
> In particular
> 
>    wxFileOutputStream outfile(fileName);
>    outfile.Write(wxMemoryInputStream(m_buffer));
> 
> must be changed:
> 
>    wxFileOutputStream outfile(fileName);
>    wxMemoryInputStream tmp(m_buffer)
>    outfile.Write(tmp);

Thanks a lot! I already made the necessary changes.

> Also code like
> 
>     for (int i=.... ) {
>     }
> 
> must be turned into:
> 
>     int i;
>     for (i=.... ) {
>     }

Thanks again. I changed all for-loops to not use variable definitions.

> The two errors above are the price to pay when you use a compiler like
> MSVC ;-) 

Well, maybe I should install mingw in addition to MSVC to do such 
checks myself.

Regards,

Ulrich
-- 
E-Mail privat:  Ulr...@gm...
E-Mail Studium: Ulr...@Fe...
World Wide Web: http://www.stud.fernuni-hagen.de/q1471341

Re: [wxCode-users] wxCode categories (please ALL read)

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

> 'window container', 'dialog', 'control', 'window layout',
> 'networking', 'stream', 'database',
> 'data container',
> 'graphics'
> 'text processing'
> 'printing'
> 'import/export'
> 'system',
> 'tutorials/documentation' ,
> 'application'
> 'miscellaneous',
> 'wrapper'
> 



>>>I added
>>>graphics, text, and system (hardware and platform dep stuff here),
>>
>>I think it's a good idea group together platform-dependent stuff but I don't know if
>>"graphics, text, and system" are good names; they sounds too generic for me...
>>
>>wx docs have a "device contexts" category; maybe this is better than "graphics" (even if
>>to be honest "device contexts" sounds a little bit too specific for me ;-))
> 
> 
> I think graphics could cover wxImage stuff and wxDC anything to do
> with drawing and images, wxPlot could go here then. wxPDFDocument
> could be import/export and graphics.
after looking at the component list, I see that it's not so generic.... so it's okay for me.


>>text what would group ?
> 
> Text processing, wxScintilla, wxSpellcheck...
ok, "text processing" is a better name ;)



>>system instead would be useful, for example for UnixfileDataClass; however to make it
>>clear it's platform dependent stuff I would call it "system-dependent"...
> 
> 
> I think just calling it "system" would allow it to cover wxCTB (serial
> port) as well as filesystem stuff, there will probably only be a
> couple of these.
the best option would probably to create something like "hardware" for wxCTB but I think 
wxCTB would be the only component inside it :-)
So "system" is okay, after all.

Francesco

Re: [wxCode-users] wxCode categories (please ALL read)

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

'window container', 'dialog', 'control', 'window layout',
'networking', 'stream', 'database',
'data container',
'graphics'
'text processing'
'printing'
'import/export'
'system',
'tutorials/documentation' ,
'application'
'miscellaneous',
'wrapper'

> >I added
> > graphics, text, and system (hardware and platform dep stuff here),
> I think it's a good idea group together platform-dependent stuff but I do=
n't know if
> "graphics, text, and system" are good names; they sounds too generic for =
me...
>=20
> wx docs have a "device contexts" category; maybe this is better than "gra=
phics" (even if
> to be honest "device contexts" sounds a little bit too specific for me ;-=
))

I think graphics could cover wxImage stuff and wxDC anything to do
with drawing and images, wxPlot could go here then. wxPDFDocument
could be import/export and graphics.
=20
> text what would group ?

Text processing, wxScintilla, wxSpellcheck...

> system instead would be useful, for example for UnixfileDataClass; howeve=
r to make it
> clear it's platform dependent stuff I would call it "system-dependent"...

I think just calling it "system" would allow it to cover wxCTB (serial
port) as well as filesystem stuff, there will probably only be a
couple of these.

-John Labenski

Re: [wxCode-users] wxCode categories (please ALL read)

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

'window container', 'dialog', 'control', 'window layout',
'networking', 'stream', 'database',
'data container',
'graphics' or 'device contexts' ?
'text??'
'printing'
'import/export'
'system-dependent',
'tutorials/documentation' ,
'application'
'miscellaneous',
'wrappers'

>>From what I gathered, this is what the list would look like? 
I would add 'wrappers' as written in a previous mail...

>I added
> graphics, text, and system (hardware and platform dep stuff here),
I think it's a good idea group together platform-dependent stuff but I don't know if 
"graphics, text, and system" are good names; they sounds too generic for me...

wx docs have a "device contexts" category; maybe this is better than "graphics" (even if 
to be honest "device contexts" sounds a little bit too specific for me ;-))

text what would group ?

system instead would be useful, for example for UnixfileDataClass; however to make it 
clear it's platform dependent stuff I would call it "system-dependent"...

> removed the word "classes" and made them not plural.
thanks


Francesco

PS: John, what you think of the multiple-categories proposal ?

Re: [wxCode-users] wxCode categories (please ALL read)

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

'window container', 'dialog', 'control', 'window layout',
'networking', 'stream', 'database',=20
'data container',
'graphics'
'text'
'printing'
'import/export'
'system',=20
'tutorials/documentation' ,=20
'application'
'miscellaneous',

* when replying, put your complete list at the top

From what I gathered, this is what the list would look like? I added
graphics, text, and system (hardware and platform dep stuff here),
removed the word "classes" and made them not plural.

Regards,
    John Labenski

[wxCode-users] Cron job: test is pending approval

[Francesco M. <fr...@us...>]

name: test
wxversion: 
category: managed windows
category2: 
language: cpp
description: Put here 5-6 lines of description...
location: test
cdate: 2004-09-20
id: 100
status: alpha
docs: notavailable
buildsys: 
extdep: none
wiki: disabled
wxport: 
samples: 0
approved: 0
author: me
version: 1.0
maintainerid: 1

Maintainer SF username: frm
Maintainer name: Francesco Montorsi
Maintainer mail address: fr...@us...

[wxCode-users] About wxpdfdoc

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

Hi,

 >>>The third problem is not really a big problem, but a bit inconvenient:
 >>>> > the warning level is set to 4 in the dsp files by bakefile. This leads
 >>>> > to dozens of warnings which can savely be ignored, but it makes
 >>>> > locating error messages more diffcult.
 >>
 >>> do you mean the crash I told you in the last mail ?
 >
 >
 >No. If you set the warning level to 4 before compiling minimal.cpp
 >you'll see what I mean. At least in the Unicode DLL Debug build I get
 >30 warnings, almost all in MSVC standard include files.
sorry I did read what you said in the last mail too quickly: I now understand what you are 
talking about. I always build in static Unicode Debug mode thus I don't have the DLL 
problem but I do see various warnings when I set to 4 the warning level.
This lead me to find some problems.

In particular

   wxFileOutputStream outfile(fileName);
   outfile.Write(wxMemoryInputStream(m_buffer));

must be changed:

   wxFileOutputStream outfile(fileName);
   wxMemoryInputStream tmp(m_buffer)
   outfile.Write(tmp);

since mingw32, GCC and all other ANSI-compliant compilers won't accept this. I attach as 
example the error log from mingw. Otherwise the code compiles with MSVC only.
Also code like

    for (int i=.... ) {
    }

    printf("%d", i);

must be turned into:

    int i;
    for (i=.... ) {
    }

    printf("%d", i);

since for ANSI C++ the "i" died inside the FOR loop (but not for MSVC).

The two errors above are the price to pay when you use a compiler like MSVC ;-)

Francesco

Re: [wxCode-users] wxCode categories (please ALL read)

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

Hi,

> I meant to say that from phpMyAdmin before updating the values in the
> "category" field, you need to go in the "categories" table and look
> the ID of the category name you want to set; not a major issue
> obviously... 

Obviously not, since you have to know the IDs of the categories 
regardless of where you enter them, into the component table or in any 
other table.

> I meant that the PHP code would have been more complex :-)

So what? These extra lines of code are written only once.

> > probably very few components will have more than one or two assicated 
> > categories, but in case a component fits in more categories the 
> > maintainer would be free to do so.
> this is why I'm reluctant to add this... few components would need it.

I knew this argument would come. :-)

Nevertheless I think it's a good idea to be prepared for components 
which fit in more than one category. There already are such components 
in wxCode.

> > SET type is not SQL standard.
> ops; I'm not so expert in databases: I did not know when I created the
> components table that SET is MySQL-specific. 

It is, but most probably MySQL will be around long enough so we don't 
need to worry about that.

> Still, since I know how to handle SETs reliably in PHP and I have
> already some utility functions in the website for them, I would prefer
> this way rather than a new table, if we are going to add the
> multiple-categories feature. 

In my opinion the multiple-catgories feature should be added. It's ok 
to use the MySQL SET type to implement it.

> > 'print/import/export'
> that could be another good name but breaks the logical "link" between
> the PRINT concept and the EXPORT concept which have much in common.
> maybe it's best to add 
>     'import' and 'print/export'
> or
>     'import/export' and 'print'

The latter seems to be more appropriate.

> Here is a small fix adapted from my components to the tutorial3 of your comp:

Thanks. Maybe a better approach would be to change the working 
directory in minimal.cpp, otherwise I would have to change each example 
program which needs to access files. Unfortunately there is no 
wxSetCwd.

> > The DLL is placed into the folder 'lib', but if you execute the application, 
> > the DLL is not found if it is not located in the samples folder or the 
> > lib folder is not contained in the PATH environment variable.
> yes, I know; I have the same problem with my comopnents.
> And I don't know if there is some good system to avoid this.

I've no idea either. :-(

> Maybe I should set wxCode bakefiles so that the DLL goes in the
> "samples" folder...

No, please don't do that. The lib folder is the right place for LIB and 
DLL files. 

> but then it would be not very intuitive for the user: he should copy
> the .lib from the LIB folder and the .dll from the SAMPLES folder... 

This should be avoided.

Unfortunately I don't know whether it is possible in MSVC6 to specify 
where DLLs should be searched, when excuting/debugging an application 
from within MSVC.

> > The third problem is not really a big problem, but a bit inconvenient: 
> > the warning level is set to 4 in the dsp files by bakefile. This leads 
> > to dozens of warnings which can savely be ignored, but it makes 
> > locating error messages more diffcult.
> do you mean the crash I told you in the last mail ?

No. If you set the warning level to 4 before compiling minimal.cpp 
you'll see what I mean. At least in the Unicode DLL Debug build I get 
30 warnings, almost all in MSVC standard include files.

> > Maybe I should write a small readme file mentioning these issues.
> I strongly suggest you to do so: otherwise you'll get tons of mails of
> user asking help all on this same matter :-) 

Yeah, I guess you're absolutely right.

Ulrich
-- 
E-Mail privat:  Ulr...@gm...
E-Mail Studium: Ulr...@Fe...
World Wide Web: http://www.stud.fernuni-hagen.de/q1471341

Re: [wxCode-users] wxCode categories (please ALL read)

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

Hi,

>>However we should consider that
>>1) this will make more difficult for wxCode administrators to edit
>>component categories when using the phpMyAdmin interface for editing,
>>for example, unmaintained components. 
> 
> 
> Why? In my view it is not more complicate to check one or more category 
> check boxes than selecting two categories from list boxes. And if you 
> do it directly on the database you write two inserts instead of one, 
> and one of them is very simple having only the component name and the 
> category name as values.
well, I meant to say that from phpMyAdmin before updating the values in the "category" 
field, you need to go in the "categories" table and look the ID of the category name you 
want to set; not a major issue obviously...


>>2) this would make the website even more complex and more than 2
>>categories are not required I think. 
> 
> 
> I don't think so. The size of the list of categories is not influenced 
> by associating more than one or two categories to a component.
I meant that the PHP code would have been more complex :-)
As you said, the size of the category links in the complist is not a problem.


> And 
> probably very few components will have more than one or two assicated 
> categories, but in case a component fits in more categories the 
> maintainer would be free to do so.
this is why I'm reluctant to add this... few components would need it.


>>another solution instead of using a different table for "categories"
>>would be to use for the "category" field the SET type. this is what
>>I'm doing currently for the wx ports, versions, and build system
>>fields (which are rendered using listboxes but they could be rendered
>>also with checkboxes). 
> 
> That's clearly an option, although it makes the application dependent 
> on the MySQL database since the SET type is not SQL standard.
ops; I'm not so expert in databases: I did not know when I created the components table 
that SET is MySQL-specific.
Still, since I know how to handle SETs reliably in PHP and I have already some utility 
functions in the website for them, I would prefer this way rather than a new table, if we 
are going to add the multiple-categories feature.


>>why don't use a category like 'print/export' ?
> 
> Excellent. To make it still a bit less specific we could call it 
> 'print/import/export'
that could be another good name but breaks the logical "link" between the PRINT concept 
and the EXPORT concept which have much in common.
maybe it's best to add
    'import' and 'print/export'
or
    'import/export' and 'print'


>>The only issue: if you use MSVC6 to run the sample, then it will run
>>with working directory the "build" folder. Unfortunately this cannot
>>be set in the DSP / DSW files by bakefile since this setting is stored
>>in the OPT file. This results in a crash of tutorial samples > 3 to
>>open the 20k_c1.txt, etc files... 
> 
> 
> To be frank, it's not the only issue with MSVC6. 
> 
> As you mentioned it would be necessary to set the working directory 
> when running the application from within MSVC (if you start it from the 
> command prompt in the samples directory it works without problems. But 
> there seems to be no way to do that using bakefiles.
Here is a small fix adapted from my components to the tutorial3 of your comp:


void
tutorial3()
{
  wxString path = wxGetCwd();

  // in case this program is running from the BUILD folder...
  if (path.Right(5) == wxT("build"))
	 path = path.Left(path.Len() - 6) + wxFileName::GetPathSeparator() + wxT("samples");
  if (path.Last() != wxFileName::GetPathSeparator())
	 path += wxFileName::GetPathSeparator();

   PdfTuto3 pdf;
   pdf.SetMyTitle(_T("20000 Leagues Under the Seas"));
   pdf.SetAuthor(_T("Jules Verne"));
   pdf.PrintChapter(1,_T("A RUNAWAY REEF"), path + _T("20k_c1.txt"));
   pdf.PrintChapter(2,_T("THE PROS AND CONS"),path + _T("20k_c2.txt"));
   pdf.SaveAsFile(_T("tutorial3.pdf"));
}



> Another problem arises when you build shared libraries (DLLs). The DLL 
> is placed into the folder 'lib', but if you execute the application, 
> the DLL is not found if it is not located in the samples folder or the 
> lib folder is not contained in the PATH environment variable.
yes, I know; I have the same problem with my comopnents.
And I don't know if there is some good system to avoid this.
Maybe I should set wxCode bakefiles so that the DLL goes in the "samples" folder... but 
then it would be not very intuitive for the user: he should copy the .lib from the LIB 
folder and the .dll from the SAMPLES folder...


> The third problem is not really a big problem, but a bit inconvenient: 
> the warning level is set to 4 in the dsp files by bakefile. This leads 
> to dozens of warnings which can savely be ignored, but it makes 
> locating error messages more diffcult.
do you mean the crash I told you in the last mail ?
It was not a build problems: I get no warnings/errors when building.
It was an unsafe use of wxFileInputStream in the samples which lead to an ASSERT in wx 
internal code. Obviously it disappear if I run the sample from console.

> Maybe I should write a small readme file mentioning these issues.
I strongly suggest you to do so: otherwise you'll get tons of mails of user asking help 
all on this same matter :-)

Francesco

Re: [wxCode-users] wxCode categories (please ALL read)

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

Hi,

> The best way would be to have a "categories" table and the components
> fields referring to the indexes of the right categories inside that
> table. This would avoid category duplication (like now where both
> "category" & "category2" are ENUMs with the same values). 

Exactly, since the relation between components and categories is 1 : n.

> However we should consider that
> 1) this will make more difficult for wxCode administrators to edit
> component categories when using the phpMyAdmin interface for editing,
> for example, unmaintained components. 

Why? In my view it is not more complicate to check one or more category 
check boxes than selecting two categories from list boxes. And if you 
do it directly on the database you write two inserts instead of one, 
and one of them is very simple having only the component name and the 
category name as values.

> 2) this would make the website even more complex and more than 2
> categories are not required I think. 

I don't think so. The size of the list of categories is not influenced 
by associating more than one or two categories to a component. And 
probably very few components will have more than one or two assicated 
categories, but in case a component fits in more categories the 
maintainer would be free to do so.

> In any case, before proceeding I would like to have also John's and
> Otto's opinions... 

Sure. It's good to hear several opinions before deciding.

> well, I meant that this must be avoided just telling maintainers not
> to abuse of the "miscellaneous" folder... I've added a small notice in
> the EDIT & COMPSUBMIT pages. 

A solution enforcing a consistent category association would be 
preferable.

> another solution instead of using a different table for "categories"
> would be to use for the "category" field the SET type. this is what
> I'm doing currently for the wx ports, versions, and build system
> fields (which are rendered using listboxes but they could be rendered
> also with checkboxes). 

That's clearly an option, although it makes the application dependent 
on the MySQL database since the SET type is not SQL standard.

> > For wxPdfDocument I would like to have a category like 
> > 'printing/PDF/Postcript'.
> it seems too specific , for me...

You're right ... but when I wrote the mail I had no better idea.

> why don't use a category like 'print/export' ?

Excellent. To make it still a bit less specific we could call it 
'print/import/export'

> in this way the categories would be: 
> 'window containers', 'dialogs', 'controls', 'window layout',
> 'networking', 'stream classes', 'database classes', 'miscellaneous',
> 'applications', 'tutorials/wxdocs' , 'data container', 'print/export',
> 'wrappers' 

Sounds good. 

> I've just compiled it and it's very impressive ! optimal documentation
> & optimal organization. it built without any problem and everything
> works. 

That's good news. It's always a bit tensing when publishing code 
whether it will compile and work for others or whether anything is 
missing.

> The only issue: if you use MSVC6 to run the sample, then it will run
> with working directory the "build" folder. Unfortunately this cannot
> be set in the DSP / DSW files by bakefile since this setting is stored
> in the OPT file. This results in a crash of tutorial samples > 3 to
> open the 20k_c1.txt, etc files... 

To be frank, it's not the only issue with MSVC6. 

As you mentioned it would be necessary to set the working directory 
when running the application from within MSVC (if you start it from the 
command prompt in the samples directory it works without problems. But 
there seems to be no way to do that using bakefiles.

Another problem arises when you build shared libraries (DLLs). The DLL 
is placed into the folder 'lib', but if you execute the application, 
the DLL is not found if it is not located in the samples folder or the 
lib folder is not contained in the PATH environment variable.

The third problem is not really a big problem, but a bit inconvenient: 
the warning level is set to 4 in the dsp files by bakefile. This leads 
to dozens of warnings which can savely be ignored, but it makes 
locating error messages more diffcult.

Maybe I should write a small readme file mentioning these issues.

Ulrich
-- 
E-Mail privat:  Ulr...@gm...
E-Mail Studium: Ulr...@Fe...
World Wide Web: http://www.stud.fernuni-hagen.de/q1471341

Re: [wxCode-users] wxCode categories (please ALL read)

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

Hi,

>>>1) select the same category for category1 and category2
>>
>>this is probably the best way. I would not make the PHP code even more
>>complex to handle a new ENUM value like "not applicable" since I
>>currently reused all the code to handle "category" also for
>>"category2" 
> 
> 
> Well, in the end it would be better to have a separate table in the 
> database for registering the categories of a component than two 
> category fields in the component table. This would solve most problems 
> which could arise from the current solution. It would not be a problem 
> to have a component belonging to only one category and it would not be 
> a problem to have a component belonging to more than two categories.
yes indeed. The best way would be to have a "categories" table and the components fields 
referring to the indexes of the right categories inside that table. This would avoid 
category duplication (like now where both "category" & "category2" are ENUMs with the same 
values).

However we should consider that
1) this will make more difficult for wxCode administrators to edit component categories 
when using the phpMyAdmin interface for editing, for example, unmaintained components.
2) this would make the website even more complex and more than 2 categories are not 
required I think.

In any case, before proceeding I would like to have also John's and Otto's opinions...

> 
> I know you said you are lazy, same with me. :-) 
;)


> But you should consider to invest a bit more time now to gain time in 
> the future. Let me know if you need assistance in respect to the 
> database part since I have many years of database experience.
ok, thanks.


>>>2) select miscelleaneous for category2 (which would be definitely 
>>>misleading)
>>
>>I agree that this must be avoided.
> 
> 
> How would you do that? A component maintainer could select 
> 'Miscellaneous' as the second category by purpose since his component 
> might provide aditional classes which don't fit into the selected 
> category1 and not any other specific category.
well, I meant that this must be avoided just telling maintainers not to abuse of the 
"miscellaneous" folder... I've added a small notice in the EDIT & COMPSUBMIT pages.


> In my opinion the best solution would be to provide on the "Edit 
> component" page a list of checkboxes for all available categories and 
> the maintainer checks all that apply.
another solution instead of using a different table for "categories" would be to use for 
the "category" field the SET type. this is what I'm doing currently for the wx ports, 
versions, and build system fields (which are rendered using listboxes but they could be 
rendered also with checkboxes).


>>2) some components, like "mmwx" or "awx" have many additional classes
>>inside them. I think the best thing would be to split them in single
>>components and use existing categories... but I think this will
>>require some work and maybe the authors do not agree... so which
>>category should be used for these ones if we remove "miscellaneous ? 
> 
> 
> If more than 2 categories could be associated to such components this 
> wouldn't be a problem any more, I guess. Otherwise we would end up with 
> a "miscellaneous" category whatever we call it.
unless we told the maintainers which want to indicate a single category to set both fields 
to the same value, as you suggested; this way would not require a "misc" category.


> Additionally I have a selfish argument against the 'miscellaneous' 
> category: my component wxPdfDocument would end up there. ;-)
:-)


> For wxPdfDocument I would like to have a category like 
> 'printing/PDF/Postcript'.
it seems too specific , for me... why don't use a category like 'print/export' ?
in this way the categories would be:


'window containers', 'dialogs', 'controls', 'window layout',
'networking', 'stream classes', 'database classes', 'miscellaneous',
'applications', 'tutorials/wxdocs' , 'data container', 'print/export',
'wrappers'



> (BTW: the initial version is now in CVS, and 
> I think it's stable enough to create a file release as well.)
I've just compiled it and it's very impressive !
optimal documentation & optimal organization.
it built without any problem and everything works.

The only issue: if you use MSVC6 to run the sample, then it will run with working 
directory the "build" folder. Unfortunately this cannot be set in the DSP / DSW files by 
bakefile since this setting is stored in the OPT file. This results in a crash of tutorial 
samples > 3 to open the 20k_c1.txt, etc files...

very complete and useful !


Francesco

Re: [wxCode-users] wxCode categories (please ALL read)

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

Hi,

> > 1) select the same category for category1 and category2
> this is probably the best way. I would not make the PHP code even more
> complex to handle a new ENUM value like "not applicable" since I
> currently reused all the code to handle "category" also for
> "category2" 

Well, in the end it would be better to have a separate table in the 
database for registering the categories of a component than two 
category fields in the component table. This would solve most problems 
which could arise from the current solution. It would not be a problem 
to have a component belonging to only one category and it would not be 
a problem to have a component belonging to more than two categories.

I know you said you are lazy, same with me. :-) 

But you should consider to invest a bit more time now to gain time in 
the future. Let me know if you need assistance in respect to the 
database part since I have many years of database experience.

> > 2) select miscelleaneous for category2 (which would be definitely 
> > misleading)
> I agree that this must be avoided.

How would you do that? A component maintainer could select 
'Miscellaneous' as the second category by purpose since his component 
might provide aditional classes which don't fit into the selected 
category1 and not any other specific category.

In my opinion the best solution would be to provide on the "Edit 
component" page a list of checkboxes for all available categories and 
the maintainer checks all that apply.

> > I think a choice of "not applicable" would be necessary for category2.
> I would prefer method #1 since I'm lazy... ;)

Such a category would not be necessary if we would have a separate 
table mentioned above. Zero entries would mean: no category fits.

> it sounds good to me except for one thing: even if they are
> applications, they could not be "stand alone" in the sense that they
> could require external libraries (like WebUpdate which requires
> wxHttpEngine)... maybe only "applications" is better ? 

'applications' would be ok for me.

> since the components are > 50 I would ask to everyone to consider carefully 
> the categories required for his components.

Certainly.

> Using the search page you can see all the unmaintained components.

I'll take a look.

> 1) think to IEHtmlWin, wxSpellChecker, wxXml2, wxScript, etc: they are
> mainly wrappers for wxWidgets of external libraries / components.
> maybe we should create a category like 'wrappers' ? 

Yes, that sounds good.

> 2) some components, like "mmwx" or "awx" have many additional classes
> inside them. I think the best thing would be to split them in single
> components and use existing categories... but I think this will
> require some work and maybe the authors do not agree... so which
> category should be used for these ones if we remove "miscellaneous ? 

If more than 2 categories could be associated to such components this 
wouldn't be a problem any more, I guess. Otherwise we would end up with 
a "miscellaneous" category whatever we call it.

Additionally I have a selfish argument against the 'miscellaneous' 
category: my component wxPdfDocument would end up there. ;-)

For wxPdfDocument I would like to have a category like 
'printing/PDF/Postcript'. (BTW: the initial version is now in CVS, and 
I think it's stable enough to create a file release as well.)

> > P.S.: There are still problems with the display of component's web 
> > page. [...]
> fixed both; thanks for reporting

Great. Works perfectly now. Thank you.

> > P.P.S.: For my new component wxPdfDocument I don't have screenshots, 
> > but I would like to show some example PDF documents. How should I 
> > handle this?
> if they are small (in size; i.e. < 1 Mb)

Currently about 256 kB.

> I suggest you to put them in your "website" folder so they are
> automatically synchronized with wxCode website. Otherwise, to avoid to
> overload the CVS you should manually upload them in the "doc" folder
> for your project at 
> 
> /home/groups/w/wx/wxcode/htdocs/documentation/wxpdfdoc

I think this would be the best choice since these example files 
definitely do not need versioning

> I think it will be easier for users of your component if you make
> these third-party addons available in the wxCode releases... obviously
> you can do this if this is allowed by these addons' licenses... 

These addons are LGPL as far as I know, so it would be certainly ok to 
put them in wxCode releases. But I think it would be best to make a 
separate ZIP file out of them since they will probably not change very 
often.

Ulrich
-- 
E-Mail privat:  Ulr...@gm...
E-Mail Studium: Ulr...@Fe...
World Wide Web: http://www.stud.fernuni-hagen.de/q1471341

Re: [wxCode-users] wxCode categories (please ALL read)

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

Hi,

>>Ok; I've implemented this feature and now there is an additional
>>component field called "category2" which can be set by the EDIT &
>>compsubmit forms. 
> 
> 
> In principle it is good to have the possibility to add a second 
> category to a component. But in case a component belongs to exactly 
> _one_ category the category2 field should be unassigned. As it is 
> implemented now, one has two options:
> 
> 1) select the same category for category1 and category2
this is probably the best way. I would not make the PHP code even more complex to handle a 
new ENUM value like "not applicable" since I currently reused all the code to handle 
"category" also for "category2"

> 2) select miscelleaneous for category2 (which would be definitely 
> misleading)
I agree that this must be avoided.


> I think a choice of "not applicable" would be necessary for category2.
I would prefer method #1 since I'm lazy... ;)


>>however, the complist is quite useless when browsed in "category" mode
>>since all categories must be set to their right values.  
> 
> Sure. But until now it wasn't possible to edit the category field. So 
> as soon as the list of categories is fixed, the maintainers should be 
> informed and each maintainer should then update the component entry.
Absolutely true; it was not meant to be a critic to maintainers :-)


>>John and I discussed to change them to:
>>
>>'window containers', 'dialogs', 'controls', 'window layout',
>>'networking', 'stream classes', 'database classes', 'miscellaneous',
>>'utilities', 'tutorials/wxdocs' , 'data container' 
> 
> 
> In my opinion we should try to avoid categories like ''miscellaneous' 
> or 'utilities'.
> 
> Instead of 'utilities' I would propose 'stand alone applications' - 
> although it does not say much about the purpose of the component it 
> makes clear that it's a complete program and not a library. To the 
> component "WebUpdate" one would probably then assign the categories 
> 'networking' and 'stand alone'.
it sounds good to me except for one thing: even if they are applications, they could not 
be "stand alone" in the sense that they could require external libraries (like WebUpdate 
which requires wxHttpEngine)...
maybe only "applications" is better ?


> In the case of 'miscellaneous' the matter is more complex. For how many 
> and which components none of the other categories are suitable? The 
> list of these components should be analyzed and then appropriate 
> additional categories should be introduced.
yes, right; since the components are > 50 I would ask to everyone to consider carefully 
the categories required for his components.
Using the search page you can see all the unmaintained components.

I detect two issues with these ones:

1) think to IEHtmlWin, wxSpellChecker, wxXml2, wxScript, etc: they are mainly wrappers for 
wxWidgets of external libraries / components. maybe we should create a category like 
'wrappers' ?

2) some components, like "mmwx" or "awx" have many additional classes inside them. I think 
the best thing would be to split them in single components and use existing categories... 
but I think this will require some work and maybe the authors do not agree... so which 
category should be used for these ones if we remove "miscellaneous ?


> I would propose to add a 
> category "unassigned". This would be a signal to the administrator(s) 
> of wxCode that maybe a new category has to be created. The issue could 
> be discussed with the maintainer of the component and the wxCode users, 
> whether the 'unassigned' component matches one of the existing 
> categories or a new one has to be created.
Such category would be useless after these first days of 're-categorization'... new 
components would be registered into existing categories and if someone needs new cat, 
then, as you say, we would discuss them on this list and then change that component into 
the new category...
being lazy I would avoid to create such temporary category :-)


> P.S.: There are still problems with the display of component's web 
> page. The website of my component wxSQLite3 is shown, the one of my 
> component wxPdfDocument is not. Another issue is the link to the 
> documentation. Currently a directory listing is shown.  This should be
> configured in such a way that the page 'index.html' is shown.
fixed both; thanks for reporting


> P.P.S.: For my new component wxPdfDocument I don't have screenshots, 
> but I would like to show some example PDF documents. How should I 
> handle this?
if they are small (in size; i.e. < 1 Mb) I suggest you to put them in your "website" 
folder so they are automatically synchronized with wxCode website.
Otherwise, to avoid to overload the CVS you should manually upload them in the "doc" 
folder for your project at

/home/groups/w/wx/wxcode/htdocs/documentation/wxpdfdoc


> P.P.P.S: I'd like to make two or three third party add-ons available 
> for my component wxPdfDocument, but I don't think these should be 
> included in CVS, since they are mostly binary resources. Should I make 
> file releases for these add-ons within wxCode or should I only include 
> links on the component's website where these add-ons can be found on 
> the web?
I think it will be easier for users of your component if you make these third-party addons 
available in the wxCode releases... obviously you can do this if this is allowed by these 
addons' licenses...


Francesco

Re: [wxCode-users] wxCode categories

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

Hi,

> Ok; I've implemented this feature and now there is an additional
> component field called "category2" which can be set by the EDIT &
> compsubmit forms. 

In principle it is good to have the possibility to add a second 
category to a component. But in case a component belongs to exactly 
_one_ category the category2 field should be unassigned. As it is 
implemented now, one has two options:

1) select the same category for category1 and category2
2) select miscelleaneous for category2 (which would be definitely 
misleading)

I think a choice of "not applicable" would be necessary for category2.

> complist in name mode now that I have implemented the "ignore wx
> prefix" logic is much more usable.

Yes that's definitely true.

> however, the complist is quite useless when browsed in "category" mode
> since all categories must be set to their right values. 

Sure. But until now it wasn't possible to edit the category field. So 
as soon as the list of categories is fixed, the maintainers should be 
informed and each maintainer should then update the component entry.

> John and I discussed to change them to:
> 
> 'window containers', 'dialogs', 'controls', 'window layout',
> 'networking', 'stream classes', 'database classes', 'miscellaneous',
> 'utilities', 'tutorials/wxdocs' , 'data container' 

In my opinion we should try to avoid categories like ''miscellaneous' 
or 'utilities'.

Instead of 'utilities' I would propose 'stand alone applications' - 
although it does not say much about the purpose of the component it 
makes clear that it's a complete program and not a library. To the 
component "WebUpdate" one would probably then assign the categories 
'networking' and 'stand alone'.

In the case of 'miscellaneous' the matter is more complex. For how many 
and which components none of the other categories are suitable? The 
list of these components should be analyzed and then appropriate 
additional categories should be introduced. I would propose to add a 
category "unassigned". This would be a signal to the administrator(s) 
of wxCode that maybe a new category has to be created. The issue could 
be discussed with the maintainer of the component and the wxCode users, 
whether the 'unassigned' component matches one of the existing 
categories or a new one has to be created.

Regards,

Ulrich

P.S.: There are still problems with the display of component's web 
page. The website of my component wxSQLite3 is shown, the one of my 
component wxPdfDocument is not. Another issue is the link to the 
documentation. Currently a directory listing is shown. This should be 
configured in such a way that the page 'index.html' is shown.

P.P.S.: For my new component wxPdfDocument I don't have screenshots, 
but I would like to show some example PDF documents. How should I 
handle this?

P.P.P.S: I'd like to make two or three third party add-ons available 
for my component wxPdfDocument, but I don't think these should be 
included in CVS, since they are mostly binary resources. Should I make 
file releases for these add-ons within wxCode or should I only include 
links on the component's website where these add-ons can be found on 
the web?
-- 
E-Mail privat:  Ulr...@gm...
E-Mail Studium: Ulr...@Fe...
World Wide Web: http://www.stud.fernuni-hagen.de/q1471341

Re: [wxCode-users] wxCode categories

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

Hi,

>> For the user too (as you say above). I found a few of the components
>> should be in 2 or more categories. "awx" provides dialogs and controls
>> for example. Hopefully this is possible?
> 
> this is a reasonable thing: unfortunately it would make the category 
> listing a little bit more complex. I'm performing some tests... I'll let 
> you know.
Ok; I've implemented this feature and now there is an additional component field called 
"category2" which can be set by the EDIT & compsubmit forms.

complist in name mode now that I have implemented the "ignore wx prefix" logic is much 
more usable.
however, the complist is quite useless when browsed in "category" mode since all 
categories must be set to their right values.

To do this we must first decide the final categories to include. Please everyone 
partecipate to this thread since it's important to setup things correctly now to avoid 
"recategorization" work later.

Current categories are:

'managed windows', 'miscellaneous windows', 'common dialogs', 'controls', 'window layout', 
'networking', 'stream classes', 'database classes', 'miscellaneous', 'utilities', 
'tutorials/wxdocs'

John and I discussed to change them to:

'window containers', 'dialogs', 'controls', 'window layout', 'networking', 'stream 
classes', 'database classes', 'miscellaneous', 'utilities', 'tutorials/wxdocs' , 'data 
container'

do you agree with this change ?

Let us know,
Francesco



PS: I have maintained a complist like the old one at

      wxcode.sf.net/singlepagelist.php

and I have also introduced the new page

      wxcode.sf.net/statistics.php

Re: [wxCode-users] wxCode categories

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

Hi,


>>actually, as soon as Scotland-Italy soccer match will end, I'll fix the EDIT form
1-1; start working :(


>>>Francesco, could you make it possible to select a few at once? Like wxport.
>>
>>sorry, I don't understand: what do you mean by select a few at once ? do you mean in
>>phpMyAdmin interface ?
> 
>  
> For the user too (as you say above). I found a few of the components
> should be in 2 or more categories. "awx" provides dialogs and controls
> for example. Hopefully this is possible?
this is a reasonable thing: unfortunately it would make the category listing a little bit 
more complex. I'm performing some tests... I'll let you know.


>>>managed windows - A wxWindow derived control that manages other child
>>>windows. (eg. wxSplitterWindow)
>>
>>yes
> 
> 
> They seem to think that this means it's a standalone toplevel window.
> I think the name is very confusing for our purposes. Maybe we don't
> need it at all, you either have a control or a dialog (which we'll use
> as our toplevel window category).
I agree



> Or, we could use my definition, but call it 
> window containers -  A wxWindow derived control that manages other
> child windows. (eg.wxNotebook,  wxSplitterWindow)
I would prefer to just rename it "window containers"; please feel free to do the changes 
in the categories ENUM structure with phpMyAdmin while I restore the other parts of the 
website.



>>>miscellaneous windows - dunno? isn't controls good enough?
>>
>>wx docs list under misc windows the following:
>>
>>wxPanel  A window whose colour changes according to current user settings
>>wxScrolledWindow  Window with automatically managed scrollbars
>>wxGrid  A grid (table) window
>>
>>... though I don't know how many components could go in this category...
> 
> 
> I think this is also a little confusing, basicly anything based on a
> wxWindow is a control right? It's beyond me why they'd put wxGrid into
> this categegory with wxPanel and wxNotebook. See also below about
> controls.
>  
> 
>>>controls - A wxWindow dervived control. (eg. wxButton, wxGrid, wxStaticText...)
>>>   (include non user input controls here too?)
>>
>>no controls are only windows that interact with user
> 
> 
> wxWidgets puts wxStaticBox into this though. Maybe it's good enough
> for us to just have controls. Too many categories makes it hard to
> find stuff, especially if something is a little bit of this and a
> little bit of that.
ok, then remove "misc windows".


>>>utilities -  ??? File stuff maybe?
>>
>>I added this even if not present in wx docs because I thought it could have been useful
>>but maybe that this is confusing (being 'miscellaneous' already there)
> 
> 
> Yeah, "utility" doesn't help me understand what would be in this
> category. It sounds to me like this should be for standalone programs,
> I dunno like dos2unix or something like that. I'd say remove it, I
> don't see anyone using it yet.
well, for example my WebUpdate component does not provide a library or reusable source 
files: it provides a full application. thus it's an utility.
(it's categorization is out of date - currently it's miscellaneous - will change asap).
Also SplashScreen by Julian is a utility... so I do step back from my prev statement and 
would propose to keep this.

Francesco

Re: [wxCode-users] New component list

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

On 9/3/05, Francesco Montorsi <f18...@ya...> wrote:
>     just an aesthetical doubt: should we use change the view options (loo=
k at the
> component list at the top) to use radio buttons instead of listboxes ?
>=20
> the viewmodes, browseby and # of comp contain only two choices... what's =
your advice ?

Whatever is easier, I looks ok to me.

-John Labenski

Re: [wxCode-users] New component list

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

Hi,

    just an aesthetical doubt: should we use change the view options (look at the 
component list at the top) to use radio buttons instead of listboxes ?

the viewmodes, browseby and # of comp contain only two choices... what's your advice ?

Francesco


Francesco Montorsi wrote:
> I would like to start now with new component list; I tested the links 
> creator scripts and you can see the results at (for example):
> 
> http://wxcode.sourceforge.net/complinks_category_partial.inc.html
> 
> If you have any objection/comment/suggestion, please do it now,
> FM
> 
> 
> Francesco Montorsi wrote:
> 
>> Hi,
>>
>> Jorgen Bodde wrote:
>>
>>> This sounds very good! I like a categoric approach. As long as the 
>>> categories makes it easy to find controls. What do you mean with 
>>> managed controls?
>>
>>
>> When I wrote the string
>>
>> Networking (12): 1 2 | Managed windows (2): 1 | Controls (30): 1 2 3 | 
>> ...
>>
>> I was just thinking to the categories I put in the database... I took 
>> them from the wxWidgets documentation page "classes by category": as 
>> you can see the first section is "managed windows", then "misc 
>> windows", etc.
>>
>>> Maybe it is an idea to get the following categories:
>>>
>>> - Edit controls (spin controls, text edit)
>>> - Layout / Container controls (controls that can contain other controls)
>>> - Non visual networking
>>> - Non visial misc
>>
>>
>> At first I took a similar approach creating some categories like these 
>> but then I thought: maybe using wxWidgets documentation categories is 
>> better since our components are based on wx and maybe that in future 
>> some of them will be integrated directly into wx itself.
>>
>> The current categories are:
>>
>> 'managed windows', 'miscellaneous windows', 'common dialogs', 
>> 'controls', 'window layout', 'networking', 'stream classes', 'database 
>> classes', 'miscellaneous', 'utilities', 'tutorials/wxdocs'
>>
>> Unfortunately I see that I completely forgot to update the "category" 
>> listbox in the EDIT page of the website :(
>>
>> Before repairing that I'd like to decide definitevely the main 
>> categories that the DB must support (in future others categories can 
>> be added to the DB without problems).
>>
>> So, do you think it's best to stick to wx categories I listed above 
>> (maybe adding some new entry) or we should use another different set 
>> of categories ?
>>
>>> Thanks for your effort in the site!
>>> - Jorgen
>>
>>
>> Thanks to all people submitting their code to wxCode ! ;)
>>
>> Francesco
>>
>>
>> -------------------------------------------------------
>> SF.Net email is Sponsored by the Better Software Conference & EXPO
>> September 19-22, 2005 * San Francisco, CA * Development Lifecycle 
>> Practices
>> Agile & Plan-Driven Development * Managing Projects & Teams * Testing 
>> & QA
>> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
>> _______________________________________________
>> wxCode-users mailing list
>> wxC...@li...
>> https://lists.sourceforge.net/lists/listinfo/wxcode-users
>>
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> wxCode-users mailing list
> wxC...@li...
> https://lists.sourceforge.net/lists/listinfo/wxcode-users
> 

Re: [wxCode-users] wxCode categories

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

On 9/3/05, Francesco Montorsi <f18...@ya...> wrote:
> > I took some time to set the categories for some of the components, I
> > hope people don't mind. Many were just under miscellaneous when they
> > are clearly controls or something else.
> thanks !
> actually, as soon as Scotland-Italy soccer match will end, I'll fix the E=
DIT form so that
> user can update their component categories theyself ;)
> I suppose you did the changes using phpMyAdmin

Yes.

> > Francesco, could you make it possible to select a few at once? Like wxp=
ort.
> sorry, I don't understand: what do you mean by select a few at once ? do =
you mean in
> phpMyAdmin interface ?
=20
For the user too (as you say above). I found a few of the components
should be in 2 or more categories. "awx" provides dialogs and controls
for example. Hopefully this is possible?
=20
> > I think some of the category names are a little confusing, does this
> > make sense?
> please see also my thread "new component list" about the available catego=
ries.
> in short I took them from wxWidgets docs (where a also a short desc is pr=
ovided)

Thanks, for reference here's a copy of it
http://www.lpthe.jussieu.fr/~zeitlin/wxWindows/docs/wxwin_classesbycat.html=
#classesbycat

> > managed windows - A wxWindow derived control that manages other child
> > windows. (eg. wxSplitterWindow)
> yes

They seem to think that this means it's a standalone toplevel window.
I think the name is very confusing for our purposes. Maybe we don't
need it at all, you either have a control or a dialog (which we'll use
as our toplevel window category).

Or, we could use my definition, but call it=20
window containers -  A wxWindow derived control that manages other
child windows. (eg.wxNotebook,  wxSplitterWindow)

> > miscellaneous windows - dunno? isn't controls good enough?
> wx docs list under misc windows the following:
>=20
> wxPanel  A window whose colour changes according to current user settings
> wxScrolledWindow  Window with automatically managed scrollbars
> wxGrid  A grid (table) window
>=20
> ... though I don't know how many components could go in this category...

I think this is also a little confusing, basicly anything based on a
wxWindow is a control right? It's beyond me why they'd put wxGrid into
this categegory with wxPanel and wxNotebook. See also below about
controls.
=20
> > controls - A wxWindow dervived control. (eg. wxButton, wxGrid, wxStatic=
Text...)
> >    (include non user input controls here too?)
> no controls are only windows that interact with user

wxWidgets puts wxStaticBox into this though. Maybe it's good enough
for us to just have controls. Too many categories makes it hard to
find stuff, especially if something is a little bit of this and a
little bit of that.
=20
> > utilities -  ??? File stuff maybe?
> I added this even if not present in wx docs because I thought it could ha=
ve been useful
> but maybe that this is confusing (being 'miscellaneous' already there)

Yeah, "utility" doesn't help me understand what would be in this
category. It sounds to me like this should be for standalone programs,
I dunno like dos2unix or something like that. I'd say remove it, I
don't see anyone using it yet.
=20
Regards,
    -John Labenski

Re: [wxCode-users] wxCode categories

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

Hi,

John Labenski wrote:
> I took some time to set the categories for some of the components, I
> hope people don't mind. Many were just under miscellaneous when they
> are clearly controls or something else.
thanks !
actually, as soon as Scotland-Italy soccer match will end, I'll fix the EDIT form so that 
user can update their component categories theyself ;)
I suppose you did the changes using phpMyAdmin


> Francesco, could you make it possible to select a few at once? Like wxport.
sorry, I don't understand: what do you mean by select a few at once ? do you mean in 
phpMyAdmin interface ?


> I think some of the category names are a little confusing, does this
> make sense?
please see also my thread "new component list" about the available categories.
in short I took them from wxWidgets docs (where a also a short desc is provided)


> Please update it with corrections or clarifications, I'm just guessing
> what they're supposed to mean.

> 
> ================
> 
> managed windows - A wxWindow derived control that manages other child
> windows. (eg. wxSplitterWindow)
yes


> 
> miscellaneous windows - dunno? isn't controls good enough?
wx docs list under misc windows the following:

wxPanel  A window whose colour changes according to current user settings
wxScrolledWindow  Window with automatically managed scrollbars
wxGrid  A grid (table) window
wxSplitterWindow  Window which can be split vertically or horizontally
wxStatusBar  Implements the status bar on a frame
wxToolBar  Toolbar class
wxNotebook  Notebook class
wxListbook  Similar to notebook but using list control
wxChoicebook  Similar to notebook but using choice control
wxSashWindow  Window with four optional sashes that can be dragged
wxSashLayoutWindow  Window that can be involved in an IDE-like layout arrangement
wxVScrolledWindow  As wxScrolledWindow but supports lines of variable height
wxWizardPage  A base class for the page in wizard dialog.
wxWizardPageSimple  A page in wizard dialog.

... though I don't know how many components could go in this category...


> 
> common dialogs - A control that can be used as a wxDialog. 
>     (shouldn't this just be dialogs) (worded this way since it may be
> a wxMiniFrame based control)
> 
> controls - A wxWindow dervived control. (eg. wxButton, wxGrid, wxStaticText...)
>    (include non user input controls here too?)
no controls are only windows that interact with user

> 
> window layout - A layout mechanism for wxWindow derived classes. (eg. wxSizer) 
>     (not a window itself though, like managed windows) ??
exactly:

> 
> networking - A library to provide networking functions.
> 
> stream classes - A library providing stream classes. (eg. wxInput/OutputStream)
> 
> database classes - A library providing database functions.
> 
> miscellaneous - A library containing various functions.
> 
> utilities -  ??? File stuff maybe?
I added this even if not present in wx docs because I thought it could have been useful 
but maybe that this is confusing (being 'miscellaneous' already there)

> 
> tutorials/wxdocs - Documentation.
> 
> ================
> 
> To add... maybe others?
I'm open to any new category entry

> 
> data container - A library providing data containers. (eg. wxObject, wxArray)
>     (I think this may come into use)
yes, this could prove useful.

Francesco

[wxCode-users] wxCode categories

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

I took some time to set the categories for some of the components, I
hope people don't mind. Many were just under miscellaneous when they
are clearly controls or something else.

Francesco, could you make it possible to select a few at once? Like wxport.

I think some of the category names are a little confusing, does this
make sense?
Please update it with corrections or clarifications, I'm just guessing
what they're supposed to mean.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

managed windows - A wxWindow derived control that manages other child
windows. (eg. wxSplitterWindow)

miscellaneous windows - dunno? isn't controls good enough?

common dialogs - A control that can be used as a wxDialog.=20
    (shouldn't this just be dialogs) (worded this way since it may be
a wxMiniFrame based control)

controls - A wxWindow dervived control. (eg. wxButton, wxGrid, wxStaticText=
...)
   (include non user input controls here too?)

window layout - A layout mechanism for wxWindow derived classes. (eg. wxSiz=
er)=20
    (not a window itself though, like managed windows) ??

networking - A library to provide networking functions.

stream classes - A library providing stream classes. (eg. wxInput/OutputStr=
eam)

database classes - A library providing database functions.

miscellaneous - A library containing various functions.

utilities -  ??? File stuff maybe?

tutorials/wxdocs - Documentation.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

To add... maybe others?

data container - A library providing data containers. (eg. wxObject, wxArra=
y)
    (I think this may come into use)

Regards,
    John Labenski

Re: [wxCode-users] Website of wxPdfDocument doesn't show

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

> ops, sorry. This is probably related to the work I'm doing over the
> wxCode website right now. 

Ok, we'll see whether it shows up when you finished your current 
changes to the wxCode website. Let me know if I need to change 
something on my side.

> I hope to complete it this afternoon or at last tomorrow...

No problem at all, since currently there's not much to see on my 
component's website. I try to get ready the first release of my 
component this weekend.

Regards,

Ulrich
-- 
E-Mail privat:  Ulr...@gm...
E-Mail Studium: Ulr...@Fe...
World Wide Web: http://www.stud.fernuni-hagen.de/q1471341

Re: [wxCode-users] Cron job: wxMidi is pending approval

[cecilio <s.c...@gm...>]

Hi, Francesco,

> We forget to add you to the dev list of wxCode project.

Now it works perfectly. I will start uploading and setting things.

Kind regards
Cecilio

Re: [wxCode-users] removing wx from comp names

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

Francesco Montorsi wrote:
> 
> > BTW can't the "single table" mode be a single table without pages? I
> > like it most since it resembles the old components lists.
> would this still be useful ?
> I mean: we have a *lot* of components (> 50); putting them all into a single page would be
> stressing for the server and maybe not very useful...
> anyway if you find it useful I can try to implement that.
> 
For the database it shouldn't be a problem and since the layout is much
simpler for "single table" it probably also okay for the webserver. The
transfer to the user of course will be longer but then anyone could
switch to the full view.

O. Wyss

-- 
Development of frame buffer drivers: http://linux-fbdev.sf.net
Sample code snippets for wxWidgets: http://wxcode.sf.net
How to build well-designed applications: http://wyoguide.sf.net
Desktop with a consistent look and feel: http://wyodesktop.sf.net

Re: [wxCode-users] Cron job: wxMidi is pending approval

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

Hi,

> I have tried again, and re-read the documentation but my password
> doesn't work to access the CVS. In my SF account I do not appear as
> member of the wxCode project so I suspect that this could be the cause
> of the problem. I'm wondering if on appoving the submited component
> wxMidi, is there anything that you have to do to give me access to the
> CVS that could have failed?
> 
> I have tried with both, the SF password and the wxCode pwd, althoug I 
> guess that the right one to use is the SF pwd.
ok; sorry.
This was our fault (me & John :)).
We forget to add you to the dev list of wxCode project.

Please retry now,
Francesco