From: Francesco M. <f18...@ya...> - 2005-09-04 11:00:07
|
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 |