wxcode-users — Submission, Questions, Information

Re: [wxCode-users] About site reworking: News

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

Hi,

Otto Wyss wrote:
>>2) NEWS must be easy to add; SF.net tracker is easy to use but how to
>>show it in our website ?
>>I've found that it's possible to show SF.net news items in a website
>>using SF HTML data export facility
>>(http://sourceforge.net/docman/display_doc.php?docid=1502&group_id=1) so
>>I suggest to begin to use SF news system which is much more easier &
>>quicker to use rather than editing a page by hand, commit it to CVS, log
>>in SF shell servers and checkout the website in the right folder !
>>
> 
> This is a nice idea but the newest news should be on the front page.
> Maybe you could add an include or else to show 3 news item on the front
> page and add a link to a full news page.
I have in mind exactly that: with SF HTML data export you can include 
all tracker info in your webpages and thus you can embed SF news in the 
frontpage of your site...

Francesco

[wxCode-users] About site reworking: Style

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

Francesco Montorsi wrote:
> 
> 3) the STYLE of the website is a thing more subjective. I've found two
> XHTML-compliant styles which would be easy to use:
> http://www.oswd.org/viewdesign.phtml?id=1165&referer=%2Fbrowse.php%3Fpage%3D1%26sort%3Ddownloadsdesc
> 
> and
> 
> http://www.oswd.org/viewdesign.phtml?id=1192&referer=%2Fbrowse.php%3Fpage%3D1%26sort%3Ddownloadsdesc
> 
I'm not happy with eider because the navigation still scolls away. There
is a solution here "http://de.selfhtml.org/css/layouts/fixbereiche.htm"
albeit in German. Maybe you are able to deduct it from the samples., the
second last is the best.

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

[wxCode-users] About site reworking: News

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

> 2) NEWS must be easy to add; SF.net tracker is easy to use but how to
> show it in our website ?
> I've found that it's possible to show SF.net news items in a website
> using SF HTML data export facility
> (http://sourceforge.net/docman/display_doc.php?docid=1502&group_id=1) so
> I suggest to begin to use SF news system which is much more easier &
> quicker to use rather than editing a page by hand, commit it to CVS, log
> in SF shell servers and checkout the website in the right folder !
> 
This is a nice idea but the newest news should be on the front page.
Maybe you could add an include or else to show 3 news item on the front
page and add a link to a full news page.

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] About site reworking

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

Hi all,
    these are some things I thought for new wxCode website; feel free to 
give your opinion or let us know what you think is missing or what is 
superfluos...


1) create a new wxCode LOGO; something which gives the idea of an 
extension / additional components for wx; I know it's not easy to 
translate this effect in an image and also I'm very bad with graphics 
(looking at result, you won't believe it, my image.png files for my 
components took me a lot of time ;-))


2) NEWS must be easy to add; SF.net tracker is easy to use but how to 
show it in our website ?
I've found that it's possible to show SF.net news items in a website 
using SF HTML data export facility 
(http://sourceforge.net/docman/display_doc.php?docid=1502&group_id=1) so 
I suggest to begin to use SF news system which is much more easier & 
quicker to use rather than editing a page by hand, commit it to CVS, log 
in SF shell servers and checkout the website in the right folder !


3) the STYLE of the website is a thing more subjective. I've found two 
XHTML-compliant styles which would be easy to use:
http://www.oswd.org/viewdesign.phtml?id=1165&referer=%2Fbrowse.php%3Fpage%3D1%26sort%3Ddownloadsdesc

and

http://www.oswd.org/viewdesign.phtml?id=1192&referer=%2Fbrowse.php%3Fpage%3D1%26sort%3Ddownloadsdesc

which one do you suggest ?
Keep in mind that it should have a left sidebar menu; Sinorca theme (the 
first link provided above) is not frame-based but we could still modify 
it to use frames even if I think that's not required.


4) I suggest to use the following technologies for the website:
XHTML 1.0
CSS 2.0
PHP 5.0
MySQL <--- this one would be useful for components info storing and 
since it's very easy to connect to PHP, it would allow to do a lot of 
things like show components categorized by author, category, name....
A good database for wxCode would have the following fields:

-Name:     (no restrictions: both lower and upper case)
-Subdir:   lowercase unix name / link to the site which hosts the 
component if it does not a CVS repository on wxCode
-Status:   Alpha/Beta/Stable/Unmantained (last one is for administrators 
which 'disappear': i.e. become unreachable and do not admin the 
component anymore)
-Category: generic GUI / wxWindow-derived / non-GUI
-wxWidgets supported version & port:  wxMSW-2.6/wxGTK-2.5/.../all
-Docs:           doxygen/hand-written/not-available
-Build system:   bakefile-based/makefiles/project files/not-available
-External dependencies:   .... external libraries .../none
-Admin contact info:    my...@my... (i.e. an email address)
-Wiki:    enabled as comp's website/enabled/disabled
(the first one could be used by those developers who do not want to use 
the CVS /website folder and want to have a wiki-way to edit the 
components' website)
-Description: ....

The submission form would create an email to wxCode-users and when 
administrator's approval is given, the submission form would add to the 
database the new component's info.


4) the htdocs ORGANIZATION:
the website would be all in /htdocs (I omit /home/groups/w/wx/wxcode);
the components website folders would go in /htdocs/components/compname 
folders;
the components docs would go in /htdocs/docs/compname/ folders;
the components screenshots would go in /htdocs/screenshots/compname folders;
the WIKI would go in /htdocs/wiki and it would have a page (or more) for 
each component which can be used by users/developers/both for comments & 
info / component's website.


5) sections of the wxCode website which will appear on the left sidebar:
- news (synched through PHP with SF.net ones)
- about wxCode (what is it and a link to wxWidgets; some rules for the 
*users*: how to submit a buf/feature-request/patch tracker entry; how to 
subscribe wxcode-users... )
- components (the actual link to complist.php which links component 
websites, docs, screenshots, wikis, downloads)
- submit your component (an overview of wxCode services; license issues; 
rules of component administration; submission form)
- support (current support page)
- links (current links page)
- search (a google search link)


6) the wxCode component TEMPLATE: we should create a new folder in 
wxCode\template (or something like that) which provides:
1) a default dir structure for new components
2) link to the default bakefile build system
3) a simple website\index.html page which contains the sections:
- description
- screenshots
- documentation
- download details
- further enhancements
- known bugs
- contact info
which can also be used as wiki template page for those who want a wiki 
for their component's website.


All wiki, components website & wxCode website should use the same style 
for a coherent design (see point #3).

What do you think of this plan ?

Thanks,
Francesco Montorsi

Re: [wxCode-users] About site reworking

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

Hi,

>>ehm, *cough*
>>http://wxcode.sourceforge.net/components/paletteframe/index.html
>>  *cough*
> 
> 
> Heh, I didn't mean to pick on you. Thats fine, once we get a way for
> people to do it thats where people can put new ones.
yes, sure ;-)

> I also noticed that when you click on an item it tries to download this
> http://prdownloads.sourceforge.net/wxcode/<projectname>.tar.gz?download
> Is there some reasonable way to get a generic (not numbers) address
> for the "show only this release" for a component, like this.
> http://sourceforge.net/project/showfiles.php?group_id=51305&package_id=45182&release_id=257843
unfortunately, reading SF.net docs that's not possible...


> 
> If not, I think it'd be best to remove that (or just make it point to
> the cvs web dir so they can check it out before downloading) and just
> point them to this at the top of the page.
> http://sourceforge.net/project/showfiles.php?group_id=51305&package_id=45182
yes, I agree



> I hate having to download stuff that doesn't have any version info
> since you don't know what you got after a few months. Either that or
> you have to make up your own version for it.
That's true; without version info you cannot know if there is there was 
any change on the website... and I'd like to discuss this point: maybe 
some common rules for wxCode component 'versioning' could be created.
I actually was reluctant to use a version number for each component 
since they are so small... still I now think we should all use something 
like that.

Using three version numbers MAJOR.MINOR.RELEASE is the standard but 
usually it happens (at least to me) that such version string must be 
written in a lot of your project files (maybe 1 in the readme, 1 in the 
configure.in script, 1 in bakefile; they become already 3 files to edit 
for a new release !).
Since components are small & a dev does not want to loose much time 
about it (usually), it should be able to make a new release quickly and 
thus possibly we should have only a version string to edit.
Still, the user must be able to quickly find the version of the 
component he is actually using...

Actually I do not use for my components version strings but release 
dates. If the user sees that there is a fresher download on the website 
he knows he's using something old.
Still, this suffers from the same problem above; also dates are more 
annoying to use since it's easier to remember & handle version numbers.

Maybe that we should put a "version.txt" file in each component and keep 
up to date only that.
The PHP scripts of the website could scan these files and use them in 
the complist page to show to the user the last available version.

All the problems above reflect the fact that I don't have much 
experience in handling such things; in my bigger projects I usually 
write buggy script which scan some files and replace version numbers 
using SED but it would be very annoying if I had to do it also for 
wxCode components ;-)

Francesco Montorsi

Re: [wxCode-users] About site reworking

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

On 6/25/05, Francesco Montorsi <f18...@ya...> wrote:
> > I don't think anyone has full screenshots in CVS?
> ehm, *cough*
> http://wxcode.sourceforge.net/components/paletteframe/index.html
>   *cough*

Heh, I didn't mean to pick on you. Thats fine, once we get a way for
people to do it thats where people can put new ones.

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

I also noticed that when you click on an item it tries to download this
http://prdownloads.sourceforge.net/wxcode/<projectname>.tar.gz?download
Is there some reasonable way to get a generic (not numbers) address
for the "show only this release" for a component, like this.
http://sourceforge.net/project/showfiles.php?group_id=3D51305&package_id=3D=
45182&release_id=3D257843

If not, I think it'd be best to remove that (or just make it point to
the cvs web dir so they can check it out before downloading) and just
point them to this at the top of the page.
http://sourceforge.net/project/showfiles.php?group_id=3D51305&package_id=3D=
45182

I hate having to download stuff that doesn't have any version info
since you don't know what you got after a few months. Either that or
you have to make up your own version for it.

Regards,
    John Labenski

Re: [wxCode-users] New component submission

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

Joseph Blough wrote:
> 
> Thanks!  I attempted to upload the files, but I'm getting the error
> "Access denied: Insufficient Karma".  Oddly though, it did let me created
> the subdirectory tree (include, website, tests), just not commit the files
> themselves.  Do I have to wait 24 hours for permissions to propogate or
> something?
> 
If this happens then the components directory hasn't been added to the
avail file in the CVSROOT (see
http://cvs.sourceforge.net/viewcvs.py/wxcode/CVSROOT/avail?view=markup).
CVS needs some time until all servers are synched so you may have to
wait up to 24h until you can accesss your directory.

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] New component submission

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

Thanks!  I attempted to upload the files, but I'm getting the error 
"Access denied: Insufficient Karma".  Oddly though, it did let me created 
the subdirectory tree (include, website, tests), just not commit the files 
themselves.  Do I have to wait 24 hours for permissions to propogate or 
something?

Thanks.


On Sat, 25 Jun 2005, John Labenski wrote:

> On 6/25/05, Joseph Blough <jb...@um...> wrote:
>> "databaselayer" is fine with me.  Thanks!
>
> Added.
> wxCode/components/databaselayer
>
>>>> Otto, do we want to always stick to lowercase names?
>>>>
>>> In a cross-platform environment it's important that never happens the
>>> distinction via case alone of directory names. I think the directory
>>> names are only used in scripts and don't have much relevance. I usually
>>> keep any directory name lowercase except for project directories to
>>> highlight their importance. But if you have the better arguments ...
>
> No I don't, sounds good to me.
>
> Regards,
>    John Labenski
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
> _______________________________________________
> wxCode-users mailing list
> wxC...@li...
> https://lists.sourceforge.net/lists/listinfo/wxcode-users
>
>
>

Re: [wxCode-users] New component submission

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

On 6/25/05, Joseph Blough <jb...@um...> wrote:
> "databaselayer" is fine with me.  Thanks!

Added.
wxCode/components/databaselayer

> >> Otto, do we want to always stick to lowercase names?
> >>
> > In a cross-platform environment it's important that never happens the
> > distinction via case alone of directory names. I think the directory
> > names are only used in scripts and don't have much relevance. I usually
> > keep any directory name lowercase except for project directories to
> > highlight their importance. But if you have the better arguments ...

No I don't, sounds good to me.

Regards,
    John Labenski

Re: [wxCode-users] New component submission

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

"databaselayer" is fine with me.  Thanks!

On Sat, 25 Jun 2005, Otto Wyss wrote:

> John Labenski wrote:
>>
>> On 6/24/05, Joseph Blough <jb...@um...> wrote:
>>> I'd like to add a new component called "DatabaseLayer" please.
>>
>> Otto, do we want to always stick to lowercase names?
>>
>> If yes then, Joseph what unix (lowercase name) would you like?
>> "databaselayer"
>>
> In a cross-platform environment it's important that never happens the
> distinction via case alone of directory names. I think the directory
> names are only used in scripts and don't have much relevance. I usually
> keep any directory name lowercase except for project directories to
> highlight their importance. But if you have the better arguments ...
>
> 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
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> wxCode-users mailing list
> wxC...@li...
> https://lists.sourceforge.net/lists/listinfo/wxcode-users
>
>
>

Re: [wxCode-users] New component submission

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

John Labenski wrote:
> 
> On 6/24/05, Joseph Blough <jb...@um...> wrote:
> > I'd like to add a new component called "DatabaseLayer" please.
> 
> Otto, do we want to always stick to lowercase names?
> 
> If yes then, Joseph what unix (lowercase name) would you like?
> "databaselayer"
> 
In a cross-platform environment it's important that never happens the
distinction via case alone of directory names. I think the directory
names are only used in scripts and don't have much relevance. I usually
keep any directory name lowercase except for project directories to
highlight their importance. But if you have the better arguments ...

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] About site reworking

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

John Labenski wrote:
> 
> This one: /home/groups/w/wx/wxcode/readme.txt
> It's not really for public consumption, since it's just there to give
> some hints to the webmaster(s) on how things are done. Like I said,
> please add to it anything you figure out about the website that's not
> immediately obvious. I created it to help myself remember how it
> works.
> 
I won't mind if you put it into CVS as well.

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] About site reworking

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

Hi,

>>I suggest to put that readme.txt in wxCode\website CVS... ;-)
> This one: /home/groups/w/wx/wxcode/readme.txt
> It's not really for public consumption, since it's just there to give
> some hints to the webmaster(s) on how things are done. Like I said,
> please add to it anything you figure out about the website that's not
> immediately obvious. I created it to help myself remember how it
> works.
ok, I will put some notes in it once I get started; by now I'm doing 
some experiments offline with Apache 2.0 & PHP 5.0...

>>>Thirdly, for screenshots, we could create
>>>htdocs/screenshots/projectname and users put their screenshots there.
>>
>>good idea; a special folder for the screenshots would make easier to put
>>a link to them in the complist but I'm unsure about removing them from
>>CVS... they could be very useful to people who just checkout the
>>wxCode\components to choose if use/not use that component.
>>But I understand that if all dev save their screenshots in CVS we'll end
>>up with a very heavy CVS repository...
> 
> 
> I don't think anyone has full screenshots in CVS?
ehm, *cough* 
http://wxcode.sourceforge.net/components/paletteframe/index.html
  *cough*
...

> I mean, besides the
> projectname/website/image.png 160x120 ones which are quite small. I
> was refering to the "screenshots" link on wxcode.sourceforge.net
> http://wxcode.sourceforge.net/screens.html
> where people would probably want to put multiple full screenshots of
> their widget in action. (For example a 800x600 image can be over 100k,
> my 160x120 is about 10k IIRC.)
Ok, that's a good idea.

Francesco

Re: [wxCode-users] New component submission

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

On 6/24/05, Joseph Blough <jb...@um...> wrote:
> I'd like to add a new component called "DatabaseLayer" please.

Otto, do we want to always stick to lowercase names?

If yes then, Joseph what unix (lowercase name) would you like?=20
"databaselayer"

Regards,
    John Labenski

> Component: DatabaseLayer
> wxWidgets: Only tested on 2.5.x and 2.6.x so far
> Description: DatabaseLayer provides a JDBC-like interface to database I/O=
.
> So far only SQLite3 and Firebird database backends are supported. CxxTest
> unit tests are used to try and make it easier to add more database
> backends in the future.

[wxCode-users] New component submission

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

I'd like to add a new component called "DatabaseLayer" please.

Component: DatabaseLayer
wxWidgets: Only tested on 2.5.x and 2.6.x so far
Description: DatabaseLayer provides a JDBC-like interface to database I/O. 
So far only SQLite3 and Firebird database backends are supported. CxxTest 
unit tests are used to try and make it easier to add more database 
backends in the future.

[wxCode-users] Re: Active maintenance

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

I'm still the maintainer on the wxSpellChecker and ShortcutPanel 
components.  I did a little work on wxSpellChecker to get it up to 
wxWidgets 2.5.5 and Aspell 0.60.2, but unfortunately I haven't done much 
with ShortcutPanel since Jonatan Magnusson allowed me to post the 
component.  It's worked so well that it hasn't needed changes.


On Thu, 16 Jun 2005, Otto Wyss wrote:

> Since it's important for a user of wxCode to know if a component is
> actively maintained I have to know if the current maintainer is still
> taking care. The easiest way is if any maintainer sends a status report
> to the wxcode-users list every halve year. So please send a message for
> each component you still care for to the list until the end of June.
> Please name the components in the subject. Any component I don't get a
> status report will have the maintainer name on the component list
> removed and is open for other developers to take over as a maintainer.
>
> This status report might be the right time to update a component to the
> latest development point. Also don't forget to upload an image.png
> (160x120px) to your components website.
>
> I've slightly changed the meaning of the wxWidgets field in the
> component list, the first means the oldest usable version, der second
> the last tested version. This gives a better idea how well a component
> might work with a given wxWidgets release.
>
> 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] How to provide dialogs in components

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

If you like the flexibility, then XRC resources can be great.  I set up 
the wxSpellChecker component to use XRC resources for most of the dialogs, 
but one of the samples uses a hard coded dialog to demonstrate adding 
custom functionality beyond what my "cookie-cutter" XRC based dialogs 
handled.
I found out how great XRC-based dialogs could be when I asked someone 
to test the interface and tell me what he thought.  He remarked that a combo box 
on the dialog should be sorted.  Thanks to XRC resources, only a text 
editor was needed to change the combo box style and fix the problem.


On Fri, 24 Jun 2005, Francesco Montorsi wrote:

> Hi,
>   since I'm working on the "webupdate" component which will provide a dialog 
> for updating your app, the following question raised:
>
> how should we provide dialog windows in our components ?
> Using XRC files, or just hard-coded classes that build the UI ?
>
> I've never used the XRC system before and all my components (but actually 
> only keybinder has a dialog) do not use it.
>
> What is the "right" approach ?
>
>
> Thanks for your opinion,
> Francesco
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> wxCode-users mailing list
> wxC...@li...
> https://lists.sourceforge.net/lists/listinfo/wxcode-users
>
>
>

Re: [wxCode-users] About site reworking

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

On 6/24/05, Francesco Montorsi <f18...@ya...> wrote:
> > Francesco (I'm assuming you changed index.html/php), please see the
> > readme.txt in the the root directory (add to it as as necessary).
> I could not found any readme in wxCode or wxCode\components or
> wxCode\website (CVS); do you refer to the readme.txt stored in
> /home/groups/w/wx/wxcode/htdocs ?
> I suggest to put that readme.txt in wxCode\website CVS... ;-)
=20
This one: /home/groups/w/wx/wxcode/readme.txt
It's not really for public consumption, since it's just there to give
some hints to the webmaster(s) on how things are done. Like I said,
please add to it anything you figure out about the website that's not
immediately obvious. I created it to help myself remember how it
works.
=20
> > Thirdly, for screenshots, we could create
> > htdocs/screenshots/projectname and users put their screenshots there.
> good idea; a special folder for the screenshots would make easier to put
> a link to them in the complist but I'm unsure about removing them from
> CVS... they could be very useful to people who just checkout the
> wxCode\components to choose if use/not use that component.
> But I understand that if all dev save their screenshots in CVS we'll end
> up with a very heavy CVS repository...

I don't think anyone has full screenshots in CVS? I mean, besides the
projectname/website/image.png 160x120 ones which are quite small. I
was refering to the "screenshots" link on wxcode.sourceforge.net
http://wxcode.sourceforge.net/screens.html
where people would probably want to put multiple full screenshots of
their widget in action. (For example a 800x600 image can be over 100k,
my 160x120 is about 10k IIRC.)

> Just give me some time to:
> 1) understand exactly how wxCode website works actually
> 2) do my PHP experiments ;-)
> so I'll be ready to discuss about these site changes better next week ;-)

Cool.

Thanks,
    John Labenski

Re: [wxCode-users] New component submission

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

Hi,

> I've given the access rights of component/webupdate for you. I think you
> are able to upload all the files without my creating the default
> structure (Readme, website/index, ...).
> 
Thanks; no problem for the structure ;-)

Francesco

Re: [wxCode-users] How to provide dialogs in components

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

Hi,

>>how should we provide dialog windows in our components ?
>>Using XRC files, or just hard-coded classes that build the UI ?
> I hard code them, the complicated pages are created using wxDesigner.
> I try to make them reasonably extensible if at all possible. For
> example, in wxStEdit I have a preferences dialog with 7 notebook
> pages. Each page can be used independently of the others and of the
> dialog that contains them. All I do is forward the Ok, Cancel, etc
> buttons to the page before the dialog deals with them and if the page
> handles it fine, if not, fine too.
>  
> I think it's a good idea to at least separate the "page(s)" of the
> dialog from the dialog since then it'll be reusable. You can also
> provide flags to make it possible for users to get different varieties
> or add a virtual function "CreateDialog" (or whatever) so that people
> can subclass it and override it's behavior. In this case everyone will
> have to call the "CreateDialog" function after creation (you can't
> have virtual functions in the constructor).
yes; that's exactly the approach I've taken with keybinder: I created 
some "build flags" to allow customization of appearance dialog and also 
I've divided the dialog construction in various virtual functions which 
should make easier dialog-customization....

> 
> XRC makes your user link to the XRC lib so I prefer not to use that.
> It also won't make it any easier for them to reuse or change things
> anyway.
even if I think that it would be easier for the user to fine-tune the 
appearance of the dialog, I agree with you and Otto on the hardcode 
approach since it does not force the user to link to the XRC lib and is 
a (little) faster.
Still I think that in future XRC will play a more important role in wx 
GUI programming...

Francesco

Re: [wxCode-users] How to provide dialogs in components

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

John Labenski wrote:
> 
> On 6/24/05, Francesco Montorsi <f18...@ya...> wrote:
> > Hi,
> >     since I'm working on the "webupdate" component which will provide a
> > dialog for updating your app, the following question raised:
> >
> > how should we provide dialog windows in our components ?
> > Using XRC files, or just hard-coded classes that build the UI ?
> 
> I hard code them, the complicated pages are created using wxDesigner.

Same for me, IMO hardcoded is better especially for a component which
should be usable unchanged. Else you might end up with either countless
XRC files or have to merge them together.

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] About site reworking

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

Francesco Montorsi wrote:
> 
> Hi,
> 
> > It's perfect if you look into a better design of the website but I've no
> > time at the moment to help with anything.
> ok, never mind;
> I think I could:
> 1) put some CSS & XHTML in the website to make it look better
> 2) re-code PHP stuff so that it does not use the SF email system (since
> new SF docs suggest to use cronjobs, which seems to be run not very
> often...)

This would be exceptional, I hope you do it in a way so I could use it
for wyoGuide and wyoDesktop also.

> 3) maybe set up a simple wiki both for wxCode users and for wxCode
> developers...
> 
> > So just go ahead with what you
> > have in mind and I'll look into it after the summer holiday. Please keep
> > in mind that a component  should be completely managable by the owner
> > through CVS.
> sure, CVS is too much useful to forget it ;-)
> 
> Just one thing: to perform the required changes, I'll need to write over
> some files of wxCode\htdocs folder which do not have the group write
> permission set... can you add it to all wxCode site files ?
> 
I've given you access rights to the wxCode website but be carefully,
else the website can't be accessed. Maybe use a subfolder "test" or
something until you're sure it works or simply put it directly onto the
project htdocs folder without going through CVS.

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] New component submission

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

Francesco Montorsi wrote:
> 
> Hi,
> 
> > Is this a normal component or is this for wxCode handling?
> this is a normal component...
> 
>  > In other
> > words shall I put it under the components folder or directly in wxCode?
> just in wxCode\components like all other components
> 
> > This doesn't seems to have any wxWidgets code so it might be better to
> > have it outside of the components folder. Or do I understand it wrong?
> it will be wx-based just like other components ;-)
> 
I've given the access rights of component/webupdate for you. I think you
are able to upload all the files without my creating the default
structure (Readme, website/index, ...).

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] can't perform submission

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

Otto Wyss wrote:
> 
> tmonjalo wrote:
> >
> Okay read once how to make a component and try to figure out how the
> "Readme" should look like (see component wxTreeListCtrl)  and send the
> content to me. Deside carefully if the directory name is "led" or
> wxled".  Both forms are possible.
> 
Component added. I've changed the file structor a little so it matches
with all the other components, just look in the CVS. You may change this
structure if you don't like it but for the sake of all other components
I prefer if you leave it that way.

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] How to provide dialogs in components

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

On 6/24/05, Francesco Montorsi <f18...@ya...> wrote:
> Hi,
>     since I'm working on the "webupdate" component which will provide a
> dialog for updating your app, the following question raised:
>=20
> how should we provide dialog windows in our components ?
> Using XRC files, or just hard-coded classes that build the UI ?

I hard code them, the complicated pages are created using wxDesigner.
I try to make them reasonably extensible if at all possible. For
example, in wxStEdit I have a preferences dialog with 7 notebook
pages. Each page can be used independently of the others and of the
dialog that contains them. All I do is forward the Ok, Cancel, etc
buttons to the page before the dialog deals with them and if the page
handles it fine, if not, fine too.
=20
I think it's a good idea to at least separate the "page(s)" of the
dialog from the dialog since then it'll be reusable. You can also
provide flags to make it possible for users to get different varieties
or add a virtual function "CreateDialog" (or whatever) so that people
can subclass it and override it's behavior. In this case everyone will
have to call the "CreateDialog" function after creation (you can't
have virtual functions in the constructor).

XRC makes your user link to the XRC lib so I prefer not to use that.
It also won't make it any easier for them to reuse or change things
anyway.

> I've never used the XRC system before and all my components (but
> actually only keybinder has a dialog) do not use it.
>=20
> What is the "right" approach ?

Whatever makes you happy? Seriously though, maybe someone has better
suggestions.

Regards,
    John Labenski