wxcode-users

[wxCode-users] About site reworking

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

Hi Otto,
    I know that since some SF.net changes, wxCode submission form does 
not work well anymore... since I'm going to learn PHP for other reasons 
I'd like to help you with a site enhancement - something like what were 
said in the wx thread 'wxCode & wxWidgets' - that will make the site 
more look-pleasant and the content more accessible...

is it okay ?

Let me know,
Francesco Montorsi

Re: [wxCode-users] About site reworking

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

Hi Francesco,

Francesco Montorsi wrote:
> 
> Hi Otto,
>     I know that since some SF.net changes, wxCode submission form does
> not work well anymore... since I'm going to learn PHP for other reasons
> I'd like to help you with a site enhancement - something like what were
> said in the wx thread 'wxCode & wxWidgets' - that will make the site
> more look-pleasant and the content more accessible...
> 
> is it okay ?
> 
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. 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.

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,

> 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...)
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 ?

Thanks,
Francesco

Re: [wxCode-users] About site reworking

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

On 6/23/05, Francesco Montorsi <f18...@ya...> wrote:
> > It's perfect if you look into a better design of the website but I've n=
o
> > 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
...
> 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 ?

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).

You have to get the CVS version of the website, edit files locally,
commit, and then do a checkout at SF using the script wxCode-website
or just run the parts of it that are necessary for your changes.

-------------

Secondly, do we want to have doxygen docs in wxCode's CVS? They're
pretty large and checking out wxCode is already pretty slow. I think
that just providing a doxygen.cfg file for people to run may be enough
since doxygen is easy to use. We could also make them available to
people by putting them up on the website in
htdocs/doxygen/projectname. That way people can refer to them online
and if they really want a local copy either provide a zipped version
(also stored in htdocs/doxygen/projectname) or like I said, just ask
them to run doxygen themselves. Each individual maintainer would add
these using ssh (probably using scp) as suits them.

Thirdly, for screenshots, we could create
htdocs/screenshots/projectname and users put their screenshots there.
We could provide a sample template for people to use if they like,
just so long as they have an index.html it'll work. All the developers
for wxcode have ssh rights if I understand correctly, so they'll have
to manage this aspect themselves. Again, I don't think it would be a
good idea to put these in CVS since they're binary and when you
download a component you'll have no need or want to have them. (Maybe
this could be made easier with a wiki, but I don't know anything about
that.)

Just some thoughts,
    John Labenski

Re: [wxCode-users] About site reworking

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

Hi,

> 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... ;-)


> You have to get the CVS version of the website, edit files locally,
> commit, and then do a checkout at SF using the script wxCode-website
> or just run the parts of it that are necessary for your changes.
ok, perfect.

> Secondly, do we want to have doxygen docs in wxCode's CVS? They're
> pretty large and checking out wxCode is already pretty slow.
sorry for that, I stored doxygen docs for some components in CVS... I'll 
remove them ASAP

> I think
> that just providing a doxygen.cfg file for people to run may be enough
> since doxygen is easy to use. We could also make them available to
> people by putting them up on the website in
> htdocs/doxygen/projectname.
> That way people can refer to them online
> and if they really want a local copy either provide a zipped version
> (also stored in htdocs/doxygen/projectname) or like I said, just ask
> them to run doxygen themselves. Each individual maintainer would add
> these using ssh (probably using scp) as suits them.
I agree, this is a good solution.


> 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...

> We could provide a sample template for people to use if they like,
> just so long as they have an index.html it'll work. All the developers
> for wxcode have ssh rights if I understand correctly, so they'll have
> to manage this aspect themselves. Again, I don't think it would be a
> good idea to put these in CVS since they're binary and when you
> download a component you'll have no need or want to have them. (Maybe
> this could be made easier with a wiki, but I don't know anything about
> that.)
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 ;-)

Francesco Montorsi

PS: I won't make any modifications to wxCode website without first 
mailing it to 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] 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] 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] 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

[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

[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: 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

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

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

Hi,

>>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.
it took me some time but I finally managed to modify the Sinorca theme 
to work in fixed mode navigation... I attach to this mail a little zip 
containing the modified sinorca index page.
The problem is that in broken IE the sidebar menu still results 
non-fixed and scrolls together with the page... but on my great Firefox 
it works perfectly... I think this is an acceptable behaviour.

Let me know,
Francesco

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

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

Francesco Montorsi wrote:
> 
> > 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.
> it took me some time but I finally managed to modify the Sinorca theme
> to work in fixed mode navigation... I attach to this mail a little zip
> containing the modified sinorca index page.
> The problem is that in broken IE the sidebar menu still results
> non-fixed and scrolls together with the page... but on my great Firefox
> it works perfectly... I think this is an acceptable behaviour.
> 
Your zip didn't got through the mailing list. Best if you can just move
the page to the folder "htdocs/test" of wxCode.

Firefox is good and the behaviour for IE is acceptable.

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: Style

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

Hi,

> Your zip didn't got through the mailing list. Best if you can just move
> the page to the folder "htdocs/test" of wxCode.
done; you can access it using the link:

http://wxcode.sourceforge.net/test/



> Firefox is good and the behaviour for IE is acceptable.
I managed to fix the page also for IE !
It's now fully compliant ;-)

Francesco

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

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

Francesco Montorsi wrote:
> 
> http://wxcode.sourceforge.net/test/
> 
> > Firefox is good and the behaviour for IE is acceptable.
> I managed to fix the page also for IE !
> It's now fully compliant ;-)
> 
Perfect. 2 small points, the Goole search field is too wide for the
column in a 800x600 display and I would draw a small border around the
scrollable window. Just fill in once the texts of the current front 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: Style

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

Hi,

> Perfect.
;-)

> 2 small points, the Goole search field is too wide for the
> column in a 800x600 display
I replaced the size attribute from that INPUT tag with WIDTH=90% but I 
cannot test it on my PC (which uses 1024x768)...

> and I would draw a small border around the
> scrollable window. Just fill in once the texts of the current front page.
added; still I like the page without it since the highlighted button has 
a white background colour which matches the page suggesting to the user 
a 'connection' between the button and the content... however this is a 
minor point...

by now, I'm working on PHP scripts + mySQL locally; I hope the slightly 
different versions used by SF won't give me much troubles when switching...

Francesco

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

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

Francesco Montorsi wrote:
> 
> > and I would draw a small border around the
> > scrollable window. Just fill in once the texts of the current front page.
> added; still I like the page without it since the highlighted button has
> a white background colour which matches the page suggesting to the user
> a 'connection' between the button and the content... however this is a
> minor point...
> 
Just think I always browse the net with my own background (white) ;-)

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,
    need to correct/comment myself ;-)

> 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 ;-))
I've now access to 3d studio max 5 which can be used (improperly) to 
generate 3d logos... however I wonder if Jorgen Bodde could help us with 
graphics; I remember he said on wx mailing list he was good in these 
things...


> 4) I suggest to use the following technologies for the website:
> XHTML 1.0
> CSS 2.0
> PHP 5.0
I checked and I've found that SF still uses 4.3 so we must adapt...
Also, if we want to use a database in the website (I strongly suggest 
this), we need to opt-in for database usage in SF administration page -> 
Shell/DB/Web page (which I cannot access...)

Francesco

Re: [wxCode-users] About site reworking

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

Francesco Montorsi wrote:
> 
> I've now access to 3d studio max 5 which can be used (improperly) to
> generate 3d logos... however I wonder if Jorgen Bodde could help us with
> graphics; I remember he said on wx mailing list he was good in these
> things...
> 
I'd love if someone updates the graphics on wyoGuide/wyoDesktop ;-)

> > 4) I suggest to use the following technologies for the website:
> > XHTML 1.0
> > CSS 2.0
> > PHP 5.0
> I checked and I've found that SF still uses 4.3 so we must adapt...
> Also, if we want to use a database in the website (I strongly suggest
> this), we need to opt-in for database usage in SF administration page ->
> Shell/DB/Web page (which I cannot access...)
> 
What access do you need?

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've now access to 3d studio max 5 which can be used (improperly) to
>>generate 3d logos... however I wonder if Jorgen Bodde could help us with
>>graphics; I remember he said on wx mailing list he was good in these
>>things...
>>
> 
> I'd love if someone updates the graphics on wyoGuide/wyoDesktop ;-)
I'll ask him... :-)

>>I checked and I've found that SF still uses 4.3 so we must adapt...
>>Also, if we want to use a database in the website (I strongly suggest
>>this), we need to opt-in for database usage in SF administration page ->
>>Shell/DB/Web page (which I cannot access...)
> 
> What access do you need?
Only people with full administrative rights can open the

https://sourceforge.net/project/admin/database.php?group_id=51305

page... i.e. only you or John...

Francesco

Re: [wxCode-users] About site reworking

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

Francesco Montorsi wrote:
> 
> > What access do you need?
> Only people with full administrative rights can open the
> 
> https://sourceforge.net/project/admin/database.php?group_id=51305
> 
> page... i.e. only you or John...
> 
No problem, you are now a project manager 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,

> No problem, you are now a project manager as well.
Thanks.

However I see that a wxCode database already exists; it also already 
have some data in it (2 tables, components & newadds...)... were you 
already using it ?

Francesco

Re: [wxCode-users] About site reworking

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

Hi,

> However I see that a wxCode database already exists; it also already 
> have some data in it (2 tables, components & newadds...)... were you 
> already using it ?
besides this database issue (also I'd like to inform you that I've 
changed the password to 'test' to be able to access it...) I want to ask 
a thing:

since Sinorca webtheme requires quite a lot of code repetition (like any 
other theme which is XHTML compliant) I've found successful two 
different types of solutions:

1) use PHP include() statement in all files to include the repeated 
stuff. Advantages: easy ! Disavantages: requires work from the server on 
each page request...

2) use an XSLT file which takes the text from rough XML files and then 
produces the well-formatted XHTML files; this could be set up to be done 
in real-time on each page request (but this would be useless since we 
are already using PHP technology for other things and this would be like 
solution #1 just using a different - perhaps slower - approach!) or to 
be done offline using an XSLT processor.
This requires to have
- iconv.dll
- libxml2.dll
- libxslt.dll
- zlib1.dll
- libexslt.dll
- xsltproc.exe
installed on the PC in order to have XSLTPROC working....
the advantage of doing the XHTML generation offline is that the server 
then needs only to send the page to the user and thus is faster.
However since we will be using PHP for other things (like mySQL access) 
the pages still would require webserver processing and thus I suggest to 
use approach #1.

Francesco