Hi, In Boost.Geometry we recently added a readme file (currently only in develop branch http://github.com/boostorg/geometry/tree/develop) and some basic wiki. From one of the discussions (by Mateusz Loskot): What I'd suggest is to create README.{md|markdown} file in root directory of geometry repo: have big heading on top [LOGO] Boost.Geometry The readme could also explain briefly what's around, what is include folder, what is example, test folder. and link to the main documentation and wiki pages. GitHub has somewhat 'trained' people there always is a README file (seehttp://tom.preston-werner.com/2010/08/23/readme-driven-development.html) so many users expect to use it as a first contact with a project. I believe having those files in all submodules would have a positive impact on the GitHub community and the users. Furthermore the style of those files could be more or less unified. Therefore I've prepared semi-consistent set of logos for some of the libraries: http://github.com/awulkiew/boost-logos. I decided to achieve the consistency by using the Boost logo as a base. Let me know what do you think about it. And don't hesitate to write about your ideas or propose changes. Regards, Adam
On 13 December 2013 11:23, Adam Wulkiewicz <adam.wulkiewicz@gmail.com> wrote:
In Boost.Geometry we recently added a readme file (currently only in develop branch http://github.com/boostorg/geometry/tree/develop) and some basic wiki.
From one of the discussions (by Mateusz Loskot):
What I'd suggest is to create README.{md|markdown} file in root directory of geometry repo: have big heading on top
[LOGO] Boost.Geometry
The readme could also explain briefly what's around, what is include folder, what is example, test folder. and link to the main documentation and wiki pages.
GitHub has somewhat 'trained' people there always is a README file (seehttp://tom.preston-werner.com/2010/08/23/readme-driven-development.html) so many users expect to use it as a first contact with a project.
I believe having those files in all submodules would have a positive impact on the GitHub community and the users. Furthermore the style of those files could be more or less unified. Therefore I've prepared semi-consistent set of logos for some of the libraries: http://github.com/awulkiew/boost-logos. I decided to achieve the consistency by using the Boost logo as a base.
Let me know what do you think about it. And don't hesitate to write about your ideas or propose changes.
FYI, I have asked about use of README some time ago, w/o replies yet http://lists.boost.org/Archives/boost/2013/12/209229.php Best regards, -- Mateusz Łoskot, http://mateusz.loskot.net
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Mateusz Loskot Sent: Friday, December 13, 2013 11:32 AM To: boost@lists.boost.org Subject: Re: [boost] [git] Submodule's readme and logo
On 13 December 2013 11:23, Adam Wulkiewicz <adam.wulkiewicz@gmail.com> wrote:
In Boost.Geometry we recently added a readme file (currently only in develop branch http://github.com/boostorg/geometry/tree/develop) and some basic wiki.
From one of the discussions (by Mateusz Loskot):
What I'd suggest is to create README.{md|markdown} file in root directory of geometry repo: have big heading on top
[LOGO] Boost.Geometry
The readme could also explain briefly what's around, what is include folder, what is example, test folder. and link to the main documentation and wiki pages.
GitHub has somewhat 'trained' people there always is a README file (seehttp://tom.preston-werner.com/2010/08/23/readme-driven-development .html) so many users expect to use it as a first contact with a project.
I believe having those files in all submodules would have a positive impact on the GitHub community and the users. Furthermore the style of those files could be more or less unified. Therefore I've prepared semi-consistent set of logos for some of the libraries: http://github.com/awulkiew/boost-logos. I decided to achieve the consistency by using the Boost logo as a base.
Let me know what do you think about it. And don't hesitate to write about your ideas or propose changes.
FYI, I have asked about use of README some time ago, w/o replies yet http://lists.boost.org/Archives/boost/2013/12/209229.php
Should it contain little more than a link to www.boost.org? Then we won't need to change much? If we don't have the release number, someone won't have to remember to change it ;-) Paul PS I think the logos are a bit too fancy - I'm not sure that we really need a different one for each library? --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
Paul A. Bristow wrote:
From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Mateusz Loskot <snip> FYI, I have asked about use of README some time ago, w/o replies yet http://lists.boost.org/Archives/boost/2013/12/209229.php Should it contain little more than a link to www.boost.org?
Then we won't need to change much?
If we don't have the release number, someone won't have to remember to change it ;-)
In the case of Boost.Math it could contain: http://boost.org/libs/math If more specific location was used, I suppose link similar to the following could be used: http://www.boost.org/doc/libs/release/libs/math/doc/html/special.html
Paul
PS I think the logos are a bit too fancy - I'm not sure that we really need a different one for each library?
There are already logos for some libraries: https://svn.boost.org/trac/boost/wiki/LibrariesLogos. Hence my proposal to use more consistent style in the case when someone would like to use it. Personally I like to see some memorable graphics in docs. But I'm far from forcing the authors to use some specific ones or any at all. Some basic, text-based README should be sufficient. Regards, Adam
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Adam Wulkiewicz Sent: Friday, December 13, 2013 1:07 PM To: boost@lists.boost.org Subject: Re: [boost] [git] Submodule's readme and logo
There are already logos for some libraries: https://svn.boost.org/trac/boost/wiki/LibrariesLogos.
These have provided people with lots of fun - but as far as 'branding' goes, they are a mess :-(
Hence my proposal to use more consistent style in the case when someone would like to use it.
Definitely.
Personally I like to see some memorable graphics in docs.
And I can see that you have had some fun with designing your much better and consisten collection. Thanks for putting in so much work on these. Others may be more enthusiastic?
But I'm far from forcing the authors to use some specific ones or any at all.
I think we should very strongly encourage a consistent look and feel of Boost libraries docs
Some basic, text-based README should be sufficient.
Sufficient, but doesn't help with 'developing the brand' so should be discouraged. Cheers Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
Hi, 2013/12/13 Paul A. Bristow <pbristow@hetp.u-net.com>
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Adam Wulkiewicz Sent: Friday, December 13, 2013 1:07 PM To: boost@lists.boost.org Subject: Re: [boost] [git] Submodule's readme and logo
There are already logos for some libraries: https://svn.boost.org/trac/boost/wiki/LibrariesLogos.
These have provided people with lots of fun - but as far as 'branding' goes, they are a mess :-(
Yes, they have their own unique styles :)
Hence my proposal to use more consistent style in the case when someone would like to use it.
Definitely.
Personally I like to see some memorable graphics in docs.
And I can see that you have had some fun with designing your much better and consisten collection. Thanks for putting in so much work on these.
Others may be more enthusiastic?
I sometimes need to do something different than writing the code ;)
But I'm far from forcing the authors to use some specific ones or any at all.
I think we should very strongly encourage a consistent look and feel of Boost libraries docs
Some basic, text-based README should be sufficient.
Sufficient, but doesn't help with 'developing the brand' so should be discouraged.
I agree with you, this was my initial idea, but people views are different and I'd like to avoid forcing them to do something against their will. Regards, Adam
Hi, 2013/12/13 Paul A. Bristow <pbristow@hetp.u-net.com>
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Adam Wulkiewicz Sent: Friday, December 13, 2013 1:07 PM To: boost@lists.boost.org Subject: Re: [boost] [git] Submodule's readme and logo
There are already logos for some libraries: https://svn.boost.org/trac/boost/wiki/LibrariesLogos.
These have provided people with lots of fun - but as far as 'branding' goes, they are a mess :-(
Yes, they have their own unique styles :)
Hence my proposal to use more consistent style in the case when someone would like to use it.
Definitely.
Personally I like to see some memorable graphics in docs.
And I can see that you have had some fun with designing your much better and consisten collection. Thanks for putting in so much work on these.
Others may be more enthusiastic?
I sometimes need to do something different than writing the code ;)
But I'm far from forcing the authors to use some specific ones or any at all.
I think we should very strongly encourage a consistent look and feel of Boost libraries docs
Some basic, text-based README should be sufficient.
Sufficient, but doesn't help with 'developing the brand' so should be discouraged.
I agree with you, this was my initial idea. But I'm a realist, a basic README is better than nothing ;) Regards, Adam
On Friday 13 December 2013 12:23:06 Adam Wulkiewicz wrote:
Hi,
In Boost.Geometry we recently added a readme file (currently only in develop branch http://github.com/boostorg/geometry/tree/develop) and some basic wiki.
From one of the discussions (by Mateusz Loskot):
What I'd suggest is to create README.{md|markdown} file in root directory of geometry repo: have big heading on top
[LOGO] Boost.Geometry
The readme could also explain briefly what's around, what is include folder, what is example, test folder. and link to the main documentation and wiki pages.
GitHub has somewhat 'trained' people there always is a README file (seehttp://tom.preston-werner.com/2010/08/23/readme-driven-development.html) so many users expect to use it as a first contact with a project.
I believe having those files in all submodules would have a positive impact on the GitHub community and the users. Furthermore the style of those files could be more or less unified. Therefore I've prepared semi-consistent set of logos for some of the libraries: http://github.com/awulkiew/boost-logos. I decided to achieve the consistency by using the Boost logo as a base.
Let me know what do you think about it. And don't hesitate to write about your ideas or propose changes.
I've taken a look at some of the logos. I don't quite like the specialized Boost icons on the left. I'd prefer the common Boost icon to be used without modifications, its white-blue color scheme looks more stylish to me. Also, multi-word names of libraries use underscore. Although it's not written anywhere to my knowledge, such names are typically spelled in one word, camelcase, without underscores (e.g. Boost.SmartPtr). Here is the discussion policy: http://www.boost.org/community/policy.html#lib_names This may not look very well on the logos though. So it's probably best to stick with the official Boost logo without library names or no logo at all.
Andrey Semashev wrote:
On Friday 13 December 2013 12:23:06 Adam Wulkiewicz wrote:
Let me know what do you think about it. And don't hesitate to write about your ideas or propose changes. I've taken a look at some of the logos. I don't quite like the specialized Boost icons on the left. I'd prefer the common Boost icon to be used without modifications, its white-blue color scheme looks more stylish to me.
Ok, and what do you think about those simple ones, without additional colors? http://github.com/awulkiew/boost-logos/blob/master/config.png http://github.com/awulkiew/boost-logos/blob/master/inspect.png http://github.com/awulkiew/boost-logos/blob/master/polygon.png http://github.com/awulkiew/boost-logos/blob/master/utility.png http://github.com/awulkiew/boost-logos/blob/master/quickbook.png
Also, multi-word names of libraries use underscore. Although it's not written anywhere to my knowledge, such names are typically spelled in one word, camelcase, without underscores (e.g. Boost.SmartPtr). Here is the discussion policy:
http://www.boost.org/community/policy.html#lib_names
This may not look very well on the logos though. So it's probably best to stick with the official Boost logo without library names or no logo at all.
Yes, the naming scheme worked well with the Geometry and later I just followed it. I tested some other schemes and they look ok: https://github.com/awulkiew/boost-logos/blob/master/smart_ptr.png Regards, Adam
On Friday 13 December 2013 14:23:58 Adam Wulkiewicz wrote:
Andrey Semashev wrote:
On Friday 13 December 2013 12:23:06 Adam Wulkiewicz wrote:
Let me know what do you think about it. And don't hesitate to write about your ideas or propose changes.
I've taken a look at some of the logos. I don't quite like the specialized Boost icons on the left. I'd prefer the common Boost icon to be used without modifications, its white-blue color scheme looks more stylish to me. Ok, and what do you think about those simple ones, without additional
colors?
http://github.com/awulkiew/boost-logos/blob/master/config.png http://github.com/awulkiew/boost-logos/blob/master/inspect.png http://github.com/awulkiew/boost-logos/blob/master/polygon.png http://github.com/awulkiew/boost-logos/blob/master/utility.png http://github.com/awulkiew/boost-logos/blob/master/quickbook.png
Yes, these look better, but I still prefer the the official Boost icon more. It's just simpler and more minimalistic, I guess.
Also, multi-word names of libraries use underscore. Although it's not written anywhere to my knowledge, such names are typically spelled in one word, camelcase, without underscores (e.g. Boost.SmartPtr). Here is the discussion policy:
http://www.boost.org/community/policy.html#lib_names
This may not look very well on the logos though. So it's probably best to stick with the official Boost logo without library names or no logo at all.
Yes, the naming scheme worked well with the Geometry and later I just followed it. I tested some other schemes and they look ok:
https://github.com/awulkiew/boost-logos/blob/master/smart_ptr.png
I don't know, neither one is particularly appealing. The last two versions are the better ones, I think. The fourth, probably, is the preferred one. Note also that there were alternative logos for the proposed libraries. I can't find them now, but there's some version in my old docs: http://boost-log.sourceforge.net/boost.png I don't have the svg, sorry. I suppose, all the logos should be in the same style, more or less.
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Andrey Semashev Sent: Friday, December 13, 2013 1:48 PM To: boost@lists.boost.org Subject: Re: [boost] [git] Submodule's readme and logo
On Friday 13 December 2013 14:23:58 Adam Wulkiewicz wrote:
Andrey Semashev wrote:
On Friday 13 December 2013 12:23:06 Adam Wulkiewicz wrote:
Let me know what do you think about it. And don't hesitate to write about your ideas or propose changes.
I've taken a look at some of the logos. I don't quite like the specialized Boost icons on the left. I'd prefer the common Boost icon to be used without modifications, its white-blue color scheme looks more stylish to me. Ok, and what do you think about those simple ones, without additional
colors?
http://github.com/awulkiew/boost-logos/blob/master/config.png http://github.com/awulkiew/boost-logos/blob/master/inspect.png http://github.com/awulkiew/boost-logos/blob/master/polygon.png http://github.com/awulkiew/boost-logos/blob/master/utility.png http://github.com/awulkiew/boost-logos/blob/master/quickbook.png
Yes, these look better, but I still prefer the the official Boost icon more. It's just simpler and more minimalistic, I guess.
Also, multi-word names of libraries use underscore. Although it's not written anywhere to my knowledge, such names are typically spelled in one word, camelcase, without underscores (e.g. Boost.SmartPtr). Here is the discussion policy:
http://www.boost.org/community/policy.html#lib_names
This may not look very well on the logos though. So it's probably best to stick with the official Boost logo without library names or no logo at all.
Yes, the naming scheme worked well with the Geometry and later I just followed it. I tested some other schemes and they look ok:
https://github.com/awulkiew/boost-logos/blob/master/smart_ptr.png
I don't know, neither one is particularly appealing. The last two versions are the better ones, I
fourth, probably, is the preferred one.
Note also that there were alternative logos for the proposed libraries. I can't find them now, but
think. The there's
some version in my old docs:
This is a 'Proposed for Boost' logo but I think we should make the 'proposed' much more prominent, perhaps in red?
I don't have the svg, sorry.
I suppose, all the logos should be in the same style, more or less. +1 for all using the existing 'brand' logo as is for all libraries. But we need an 'official' SVG version of boost.svg that works for all browsers. And I believe that the time has come to move to SVG for all graphics if possible. Even Internet Explorer 9 to 11 now supports SVG pretty well (as do most other browsers now that screen sizes range from a postage stamp up to a cinema screen with every imaginable aspect ratio and pixel density). Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
On Friday 13 December 2013 15:05:55 Paul A. Bristow wrote:
Note also that there were alternative logos for the proposed libraries. I can't find them now, but
there's
some version in my old docs:
This is a 'Proposed for Boost' logo but I think we should make the 'proposed' much more prominent, perhaps in red?
AFAIR, there were versions with the red "proposed" tag. It looked not that well so I kept the grey one in my docs.
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Andrey Semashev Sent: Friday, December 13, 2013 3:18 PM To: boost@lists.boost.org Subject: Re: [boost] [git] Submodule's readme and logo
On Friday 13 December 2013 15:05:55 Paul A. Bristow wrote:
Note also that there were alternative logos for the proposed libraries. I can't find them now, but
there's
some version in my old docs:
This is a 'Proposed for Boost' logo but I think we should make the 'proposed' much more prominent, perhaps in red?
AFAIR, there were versions with the red "proposed" tag. It looked not that well so I kept the grey one in my docs.
Mine are attached - and obviously I like them better ;-) Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
On 13 December 2013 15:05, Paul A. Bristow <pbristow@hetp.u-net.com> wrote:
And I believe that the time has come to move to SVG for all graphics if possible. Even Internet Explorer 9 to 11 now supports SVG pretty well (as do most other browsers now that screen sizes range from a postage stamp up to a cinema screen with every imaginable aspect ratio and pixel density).
I was going to say the same thing. Although I just ran a crude check on the recent server log entries and IE 8.0 appears to be the most popular version. About 4% of the total logged http requests for the past few days were from IE 6/7/8. This is not really reliable data (and I wouldn't be surprised if some of those requests have spoofed browser ids), but it's still higher than I'd expect. But it's not really a problem if these people don't see the logos on github, so I'd go for using SVG.
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Daniel James Sent: Friday, December 13, 2013 3:48 PM To: boost@lists.boost.org Subject: Re: [boost] [git] Submodule's readme and logo
On 13 December 2013 15:05, Paul A. Bristow <pbristow@hetp.u-net.com> wrote:
And I believe that the time has come to move to SVG for all graphics if possible. Even Internet Explorer 9 to 11 now supports SVG pretty well (as do most other browsers now that screen sizes range from a postage stamp up to a cinema screen with every imaginable aspect ratio and pixel density).
I was going to say the same thing. Although I just ran a crude check on the recent server log entries and IE 8.0 appears to be the most popular version. About 4% of the total logged http requests for the
few days were from IE 6/7/8. This is not really reliable data (and I wouldn't be surprised if some of those requests have spoofed browser ids), but it's still higher than I'd expect. But it's not really a
past problem if
these people don't see the logos on github, so I'd go for using SVG.
Not sure I understand this ? Did you mean IE 9.0 was the most popular IE version? (This is the first to support SVG) or "About 4% of the total logged http requests for the past few days were from IE 6/7/8 " Does this mean that of these 4%, IE8 is the most popular? Are the version of other browsers Chrome, Opera etc new enough to work with SVG? Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
On 13 December 2013 16:09, Paul A. Bristow <pbristow@hetp.u-net.com> wrote:
Not sure I understand this ?
Did you mean IE 9.0 was the most popular IE version? (This is the first to support SVG)
or
"About 4% of the total logged http requests for the past few days were from IE 6/7/8 " Does this mean that of these 4%, IE8 is the most popular?
No, IE 8 is the most popular individual version of internet explorer. The different versions are roughly at: MSIE 6.0 - 0.4% MSIE 7.0 - 1.1% MSIE 8.0 - 2.5% MSIE 9.0 - 1.5% MSIE 10.0 - 1.2% I forgot that Internet Explorer 11 uses a different browser id, so it isn't included. Take these values with a pinch of salt, it's a small sample and the methodology is pretty poor. I suspect that many of the 6.0 requests are spoofed, so that's a pretty high error.
Are the version of other browsers Chrome, Opera etc new enough to work with SVG?
They've all supported SVG for a long time: http://caniuse.com/svg
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Daniel James Sent: Friday, December 13, 2013 4:57 PM To: boost@lists.boost.org Subject: Re: [boost] [git] Submodule's readme and logo
On 13 December 2013 16:09, Paul A. Bristow <pbristow@hetp.u-net.com> wrote:
Not sure I understand this ?
Did you mean IE 9.0 was the most popular IE version? (This is the first to support SVG)
or
"About 4% of the total logged http requests for the past few days were from IE 6/7/8 " Does this mean that of these 4%, IE8 is the most popular?
No, IE 8 is the most popular individual version of internet explorer. The different versions are roughly at:
MSIE 6.0 - 0.4% MSIE 7.0 - 1.1% MSIE 8.0 - 2.5% MSIE 9.0 - 1.5% MSIE 10.0 - 1.2%
I forgot that Internet Explorer 11 uses a different browser id, so it isn't included.
Windows 7 and 8 Users will automatically get this as an update, so I suspect lots are missing from this count?
Take these values with a pinch of salt, it's a small sample and the methodology is pretty poor. I suspect that many of the 6.0 requests are spoofed, so that's a pretty high error.
Are the version of other browsers Chrome, Opera etc new enough to work with SVG?
They've all supported SVG for a long time: http://caniuse.com/svg
Thanks for clarification. I think this means we can switch to default SVG - those using IE6,7,8 really ought to upgrade anyway and all they will lose is the pictures. This will also benefit those reading on their mobile computing devices ;-) Do we have a consensus on this? Shall I start a new thread for this specific decision? Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
On 13 December 2013 18:07, Paul A. Bristow <pbristow@hetp.u-net.com> wrote:
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Daniel James Sent: Friday, December 13, 2013 4:57 PM To: boost@lists.boost.org Subject: Re: [boost] [git] Submodule's readme and logo
On 13 December 2013 16:09, Paul A. Bristow <pbristow@hetp.u-net.com> wrote:
Not sure I understand this ?
Did you mean IE 9.0 was the most popular IE version? (This is the first to support SVG)
or
"About 4% of the total logged http requests for the past few days were from IE 6/7/8 " Does this mean that of these 4%, IE8 is the most popular?
No, IE 8 is the most popular individual version of internet explorer. The different versions are roughly at:
MSIE 6.0 - 0.4% MSIE 7.0 - 1.1% MSIE 8.0 - 2.5% MSIE 9.0 - 1.5% MSIE 10.0 - 1.2%
I forgot that Internet Explorer 11 uses a different browser id, so it isn't included.
Windows 7 and 8 Users will automatically get this as an update, so I suspect lots are missing from this count?
It doesn't really matter since they changed the browser id because new Internet Explorer shouldn't be a special case. But about 1.6% of requests contain "Trident/7.0". A small number of them are running in compatibility mode, so they're acting like older versions, and are included in the list above.
On Fri, Dec 13, 2013 at 6:23 AM, Adam Wulkiewicz <adam.wulkiewicz@gmail.com>wrote:
Hi,
In Boost.Geometry we recently added a readme file (currently only in develop branch http://github.com/boostorg/geometry/tree/develop) and some basic wiki.
From one of the discussions (by Mateusz Loskot):
What I'd suggest is to create README.{md|markdown} file in root directory of geometry repo: have big heading on top
[LOGO] Boost.Geometry
The readme could also explain briefly what's around, what is include folder, what is example, test folder. and link to the main documentation and wiki pages.
GitHub has somewhat 'trained' people there always is a README file (seehttp://tom.preston-werner.com/2010/08/23/readme-driven- development.html) so many users expect to use it as a first contact with a project.
I believe having those files in all submodules would have a positive impact on the GitHub community and the users. Furthermore the style of those files could be more or less unified. Therefore I've prepared semi-consistent set of logos for some of the libraries: http://github.com/awulkiew/boost-logos. I decided to achieve the consistency by using the Boost logo as a base.
Let me know what do you think about it. And don't hesitate to write about your ideas or propose changes. \
+1 I'd suggest we (1) encourage library maintainers to provide a README, (2) suggest the Boost.Geometry README as the model, and then after some time passes (3) ask for volunteers to create README files for any libraries that don't have them. That's the sort of thing a Community Maintenance Team could manage, IMO. --Beman
On 13.12.2013 15:23, Adam Wulkiewicz wrote:
Hi,
In Boost.Geometry we recently added a readme file (currently only in develop branch http://github.com/boostorg/geometry/tree/develop) and some basic wiki.
From one of the discussions (by Mateusz Loskot):
What I'd suggest is to create README.{md|markdown} file in root directory of geometry repo: have big heading on top
[LOGO] Boost.Geometry
The readme could also explain briefly what's around, what is include folder, what is example, test folder. and link to the main documentation and wiki pages.
GitHub has somewhat 'trained' people there always is a README file (seehttp://tom.preston-werner.com/2010/08/23/readme-driven-development.html) so many users expect to use it as a first contact with a project.
I believe having those files in all submodules would have a positive impact on the GitHub community and the users. Furthermore the style of those files could be more or less unified. Therefore I've prepared semi-consistent set of logos for some of the libraries: http://github.com/awulkiew/boost-logos. I decided to achieve the consistency by using the Boost logo as a base.
Adam, thanks for trying to improve the artwork. That said, while I am not particularly proud of the logo at http://www.boost.org/doc/display_build.php/boost-build/boost-build/ I would say I still prefer it to the use of bricks metaphor, as you have in build logo. - Volodya
2013/12/13 Vladimir Prus <ghost@cs.msu.su>
On 13.12.2013 15:23, Adam Wulkiewicz wrote:
Hi,
In Boost.Geometry we recently added a readme file (currently only in develop branch http://github.com/boostorg/geometry/tree/develop) and some basic wiki.
From one of the discussions (by Mateusz Loskot):
What I'd suggest is to create README.{md|markdown} file in root directory of geometry repo: have big heading on top
[LOGO] Boost.Geometry
The readme could also explain briefly what's around, what is include folder, what is example, test folder. and link to the main documentation and wiki pages.
GitHub has somewhat 'trained' people there always is a README file (seehttp://tom.preston-werner.com/2010/08/23/readme-driven- development.html) so many users expect to use it as a first contact with a project.
I believe having those files in all submodules would have a positive impact on the GitHub community and the users. Furthermore the style of those files could be more or less unified. Therefore I've prepared semi-consistent set of logos for some of the libraries: http://github.com/awulkiew/boost-logos. I decided to achieve the consistency by using the Boost logo as a base.
Adam,
thanks for trying to improve the artwork. That said, while I am not particularly proud of the logo at
http://www.boost.org/doc/display_build.php/boost-build/ boost-build/
I would say I still prefer it to the use of bricks metaphor, as you have in build logo.
Sure, but do you like the idea of using the Boost main logo as a base? Would you like to figure something different out or just to use your version of the logo? Does the triangle on the right represent something? Regards, Adam
On 13.12.2013 22:13, Adam Wulkiewicz wrote:
2013/12/13 Vladimir Prus <ghost@cs.msu.su>
On 13.12.2013 15:23, Adam Wulkiewicz wrote:
Hi,
In Boost.Geometry we recently added a readme file (currently only in develop branch http://github.com/boostorg/geometry/tree/develop) and some basic wiki.
From one of the discussions (by Mateusz Loskot):
What I'd suggest is to create README.{md|markdown} file in root directory of geometry repo: have big heading on top
[LOGO] Boost.Geometry
The readme could also explain briefly what's around, what is include folder, what is example, test folder. and link to the main documentation and wiki pages.
GitHub has somewhat 'trained' people there always is a README file (seehttp://tom.preston-werner.com/2010/08/23/readme-driven- development.html) so many users expect to use it as a first contact with a project.
I believe having those files in all submodules would have a positive impact on the GitHub community and the users. Furthermore the style of those files could be more or less unified. Therefore I've prepared semi-consistent set of logos for some of the libraries: http://github.com/awulkiew/boost-logos. I decided to achieve the consistency by using the Boost logo as a base.
Adam,
thanks for trying to improve the artwork. That said, while I am not particularly proud of the logo at
http://www.boost.org/doc/display_build.php/boost-build/ boost-build/
I would say I still prefer it to the use of bricks metaphor, as you have in build logo.
Sure, but do you like the idea of using the Boost main logo as a base? Would you like to figure something different out or just to use your version of the logo?
I suspect that using Boost logo as a base for components will end up in too busy artwork in many cases. It might be better to just reuse font and colors.
Does the triangle on the right represent something?
Yes, construction crane. - Volodya
Hi, Vladimir Prus wrote:
On 13.12.2013 22:13, Adam Wulkiewicz wrote:
2013/12/13 Vladimir Prus <ghost@cs.msu.su>
thanks for trying to improve the artwork. That said, while I am not particularly proud of the logo at
http://www.boost.org/doc/display_build.php/boost-build/ boost-build/
I would say I still prefer it to the use of bricks metaphor, as you have in build logo.
Sure, but do you like the idea of using the Boost main logo as a base? Would you like to figure something different out or just to use your version of the logo?
I suspect that using Boost logo as a base for components will end up in too busy artwork in many cases. It might be better to just reuse font and colors.
It's all matter of figuring out the abstraction. Then this abstraction can be connected with the Boost logo. If we can't figure it out we probably won't have any logo at all. In those cases the original Boost logo could be used.
Does the triangle on the right represent something?
Yes, construction crane.
So in the case of Boost.Build the integration is simple and the idea is extendable: https://github.com/awulkiew/boost-logos/blob/master/build.png. Regards, Adam
On 14 December 2013 12:37, Adam Wulkiewicz <adam.wulkiewicz@gmail.com> wrote:
It's all matter of figuring out the abstraction. [...] So in the case of Boost.Build the integration is simple and the idea is extendable: https://github.com/awulkiew/boost-logos/blob/master/build.png.
I like this idea of abstraction + concrete feature, it works well on build.png. Best regards, -- Mateusz Łoskot, http://mateusz.loskot.net
Mateusz Loskot wrote:
On 14 December 2013 12:37, Adam Wulkiewicz <adam.wulkiewicz@gmail.com> wrote:
It's all matter of figuring out the abstraction. [...] So in the case of Boost.Build the integration is simple and the idea is extendable: https://github.com/awulkiew/boost-logos/blob/master/build.png. I like this idea of abstraction + concrete feature, it works well on build.png.
Thanks for all remarks and ideas. As a compromise I've created simple versions of logos for also for other libraries. To show you the level of consistency I've gathered them together: http://github.com/awulkiew/boost-logos/blob/master/logos.png For some libraries there are replacements (e.g. for Build, Container, Unordered) which can be found in separate files. Regards, Adam
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Adam Wulkiewicz Sent: Sunday, December 15, 2013 3:54 PM To: boost@lists.boost.org Subject: Re: [boost] [git] Submodule's readme and logo
Thanks for all remarks and ideas. As a compromise I've created simple versions of logos for also for other libraries. To show you the level of consistency I've gathered them together:
http://github.com/awulkiew/boost-logos/blob/master/logos.png
For some libraries there are replacements (e.g. for Build, Container, Unordered) which can be found in separate files.
I like these much better. (Library name might be a tad too prominent compared to Boost?) Paul PS I also like the links in the readme to build & test results. Is/can this be automated? --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
On 16 Dec 2013 at 10:10, Paul A. Bristow wrote:
PS I also like the links in the readme to build & test results. Is/can this be automated?
I have been having notions that the time to automate a buildbot dashboard is the same time as when we implement dependency support for Boost.Build. Until then it'll have to be manual I'm afraid. I'm happy of course to supply the requisite markup as a template. Paul did a great job of converting that HTML into BoostBook XML too, so you can even have your dashboard in the Boost documentation for the "Compiling" instructions like we have at https://ci.nedprod.com/view/All/job/Boost.AFIO%20Build%20Peer%20Review %20Documentation/Boost.AFIO_Documentation/doc/html/afio/compilation.ht ml so those compiling AFIO know if master is currently broken (which it currently very much is, all the unit tests fail). Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
On 16.12.2013 23:04, Niall Douglas wrote:
On 16 Dec 2013 at 10:10, Paul A. Bristow wrote:
PS I also like the links in the readme to build & test results. Is/can this be automated?
I have been having notions that the time to automate a buildbot dashboard is the same time as when we implement dependency support for Boost.Build. Until then it'll have to be manual I'm afraid.
Niall, what dependency support would you want implemented? - Volodya
On 17 Dec 2013 at 8:53, Vladimir Prus wrote:
I have been having notions that the time to automate a buildbot dashboard is the same time as when we implement dependency support for Boost.Build. Until then it'll have to be manual I'm afraid.
what dependency support would you want implemented?
Nothing crazy: http://lists.boost.org/Archives/boost/2013/10/207600.php. You'll note there I mention build bot and automated sanity test runs there too. tldr: I got told to stop discussing here and go to ryppl. Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
On 17.12.2013 09:49, Niall Douglas wrote:
On 17 Dec 2013 at 8:53, Vladimir Prus wrote:
I have been having notions that the time to automate a buildbot dashboard is the same time as when we implement dependency support for Boost.Build. Until then it'll have to be manual I'm afraid.
what dependency support would you want implemented?
Nothing crazy: http://lists.boost.org/Archives/boost/2013/10/207600.php. You'll note there I mention build bot and automated sanity test runs there too.
Making Boost's Jamroot run a script on a start is quite trivial. There's already BOOST_ROOT variable, so, something like local script = $(BOOST_ROOT)/script.sh ; if [ CHECK_IF_FILE $(script) ] { SHELL $(script) ; } sounds possible? On the other, I am not sure I understand your design goal. I am quite surely don't want any git checkouts or fetches to happen when I just build.
tldr: I got told to stop discussing here and go to ryppl.
I am somewhat lost about that ryppl thing. It seems clear that this attempt to clone Maven for C++ projects is not taking off, so I don't know why directing people to random mailing lists is gonna be helpful. - Volodya
On 17 Dec 2013 at 10:51, Vladimir Prus wrote:
what dependency support would you want implemented?
Nothing crazy: http://lists.boost.org/Archives/boost/2013/10/207600.php. You'll note there I mention build bot and automated sanity test runs there too.
Making Boost's Jamroot run a script on a start is quite trivial. [snip] sounds possible? On the other, I am not sure I understand your design goal.
It isn't that adding trivial dependency module support isn't trivial to implement, it's rather enforcing some script name and/or merging more formal support into Boost.Build and then adding in the dependencies to every Boost library.
I am quite surely don't want any git checkouts or fetches to happen when I just build.
You do if you have just cloned for the first time some Boost library. Let's take one of mine, AFIO. AFIO needs Boost.Thread (headers), Boost.ASIO (headers and/or libraries) and Boost.Filesystem (headers and libraries) to compile. Right now the end user would have to fetch each dependency by hand manually. I'm saying it would be nice if the build system took care of that for you. I'm also saying that if correctly designed, a good dependency markup design would also let you regress breaking changes by figuring out what pruned subset of unit tests to run.
tldr: I got told to stop discussing here and go to ryppl.
I am somewhat lost about that ryppl thing. It seems clear that this attempt to clone Maven for C++ projects is not taking off, so I don't know why directing people to random mailing lists is gonna be helpful.
Well, when did Boost ever not use C++ for everything? :) As much as Maven is okay, it's still just okay. Ideally we would have a build and dependency system which understands clang ASTs and therefore could be far more optimal for C++. Lot of work to build such a tool though. Or even extend Maven with such intelligence. Meanwhile, a simple nasty .bat/.sh file per git repo would actually work right now, little effort involved apart from creation of legacy baggage. Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
On Tue, Dec 17, 2013 at 11:33 AM, Niall Douglas <s_sourceforge@nedprod.com> wrote:
On 17 Dec 2013 at 10:51, Vladimir Prus wrote:
I am quite surely don't want any git checkouts or fetches to happen when I just build.
You do if you have just cloned for the first time some Boost library. Let's take one of mine, AFIO. AFIO needs Boost.Thread (headers), Boost.ASIO (headers and/or libraries) and Boost.Filesystem (headers and libraries) to compile. Right now the end user would have to fetch each dependency by hand manually. I'm saying it would be nice if the build system took care of that for you.
-1 I'd like the build system to do just that - build. What you want is a dependency tracking system. Whether it should be interoperable with the build system is a valid question, but it has to be distinct and probably support different build systems (in case of Boost it would be bjam and cmake). I had cursory (and mostly unpleasant) experience with depot tools [1], but it might be interesting for you. [1] http://www.chromium.org/developers/how-tos/install-depot-tools
Niall, On Tue, Dec 17, 2013 at 12:49 AM, Niall Douglas <s_sourceforge@nedprod.com>wrote:
tldr: I got told to stop discussing here and go to ryppl.
I certainly agree that a thread about readme files isn't the place to discuss build, test, or continuous integration. But like Volodya, I'm not at all sure ryppl is the best place for such discussions. If you don't beat me to it, I'd like to start a thread on this developers list about Continuous Testing as the predecessor to Continuous Integration. I'd start with a question to you about how you are generating your readme testing. I'm tied up, so won't get to that until later today or early tomorrow. Please, however, this needs to be a separate thread. --Beman
On 17 Dec 2013 at 11:26, Beman Dawes wrote:
I certainly agree that a thread about readme files isn't the place to discuss build, test, or continuous integration.
But like Volodya, I'm not at all sure ryppl is the best place for such discussions.
He asked me a question directly, so I answered him. I wasn't planning on elaborating as I know it isn't on the radar for the SC yet.
If you don't beat me to it, I'd like to start a thread on this developers list about Continuous Testing as the predecessor to Continuous Integration. I'd start with a question to you about how you are generating your readme testing. I'm tied up, so won't get to that until later today or early tomorrow. Please, however, this needs to be a separate thread.
Generally if I'm invited to present details, I am happy to do so. I try not to waste time presenting details no one is interested in. If you are indeed inviting me to present details, simply let me know when and where and the deadline. Please do bear in mind this week I am relocating from Canada to Ireland, tomorrow the removers come and after that comes deep cleaning where we live, selling our car, closing our bank accounts and credits cards etc. In other words, if you want lots of detail, I'd suggest a deadline shortly after Christmas. Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
I like the style and how they are more low profile when they are carved out as white. I also think it is good that boost is a bit smaller than the library name. For the icons themselves I would change a couple of the ones that look like they could easily apply to something else. Here are my thoughts on each icon: 1. array - What about something like a solar panel look or some other analogous array of physical material or objects? The current one looks a bit like a dotted line. 2. atomic - I like that one, did you also consider the classic atom symbol? This one is public domain and could be applied once the colors are swapped: http://www.clker.com/clipart-atom-1.html 3. bimap - seems good 4. bind - nice 5. boost book - love it 6. build - I guess this is the existing logo, but I would like if this was the container logo better. 7. circular buffer - love it 8. config - I know a gear is frequently used for configuration, but perhaps it should be saved for something that is for run time configuration rather than compile time? 9. container - perhaps it could be a simple treasure chest outline? The current one looks like it would be for a build system. 10. function - I like it 11. fusion - love it 12. geometry - nice, I wonder what would a simplified boost logo in a boost logo would look like for this? 13. inspect - magnifying glass is frequently used for search, though I don't have an alternative idea off hand. 14. lock free - lock is frequently used for security, perhaps an open door? 15. log - ok but not inspiring, perhaps there is a good way to capture streams aka arrows going into a drive, container, or that stack of cylinders that is sometimes used to represent data storage? 16. MPL - I like it 17. numeric conversion - what if the arrows were made a little smaller and there was a 2.0 on one end and a 2 on the other? 18. polygon - why not a simplified version of one of those nice shapes in the polygon documentation? 19. program options - this is decent, what about literally putting the text "--po" sans quotes there in the boost font? That would capture it 100% unambiguously 20. SmartPtr - It is good 21. static assert - not as enthusiastic about this one. perhaps an exclamation mark alone or an exclamation mark with sparks aka static? 22. test - fair enough, it clicks 23. tuple - nice, but needs to be better distinguished from variant 24. unordered - what about the numbers 1,3,2 in little boxes? 25. utility - the standard utility logo works for me 26. variant - I would change this to distinguish it from tuple, maybe a circle in a box and a triangle in a box? By the way what tool do you use to make those? Cheers! Andrew Hundt On Sun, Dec 15, 2013 at 10:53 AM, Adam Wulkiewicz <adam.wulkiewicz@gmail.com
wrote:
Mateusz Loskot wrote:
On 14 December 2013 12:37, Adam Wulkiewicz <adam.wulkiewicz@gmail.com> wrote:
It's all matter of figuring out the abstraction. [...] So in the case of Boost.Build the integration is simple and the idea is extendable: https://github.com/awulkiew/boost-logos/blob/master/build. png.
I like this idea of abstraction + concrete feature, it works well on build.png.
Thanks for all remarks and ideas. As a compromise I've created simple versions of logos for also for other libraries. To show you the level of consistency I've gathered them together:
http://github.com/awulkiew/boost-logos/blob/master/logos.png
For some libraries there are replacements (e.g. for Build, Container, Unordered) which can be found in separate files.
Regards, Adam
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost
Adam Wulkiewicz wrote:
Hi,
Robert Kawulak wrote:
From: Andrew Hundt 13. inspect - magnifying glass is frequently used for search, I had exactly the same thought.
though I don't have an alternative idea off hand.
How about a check mark (✓ - U+2713)?
Sure, good idea.
Or a questionare with check boxes and check marks.
Regards, Adam
Hi Andrew, Andrew Hundt wrote:
I like the style and how they are more low profile when they are carved out as white. I also think it is good that boost is a bit smaller than the library name. For the icons themselves I would change a couple of the ones that look like they could easily apply to something else. Here are my thoughts on each icon:
1. array - What about something like a solar panel look or some other analogous array of physical material or objects? The current one looks a bit like a dotted line.
I like this one: http://en.wikipedia.org/wiki/Very_Large_Array ;) There are more variants in array.svg / png but I don't like any of them. I just picked the best IMO. So if you have some idea it definietly should be tested.
2. atomic - I like that one, did you also consider the classic atom symbol? This one is public domain and could be applied once the colors are swapped: http://www.clker.com/clipart-atom-1.html
Sure may look ok.
3. bimap - seems good
If there were existing logos I wanted to use some key elements from them.
4. bind - nice
Just needs polishing.
5. boost book - love it
Yes, I like it too. Taken from the original logo.
6. build - I guess this is the existing logo, but I would like if this was the container logo better.
Check build.png
7. circular buffer - love it 8. config - I know a gear is frequently used for configuration, but perhaps it should be saved for something that is for run time configuration rather than compile time?
Yes, I know what you mean. Some switches, control lights?
9. container - perhaps it could be a simple treasure chest outline? The current one looks like it would be for a build system.
Yes it's a good idea, however I'd prefer more industrial chest. Check also container.png (connected dots - a metaphor for a list).
10. function - I like it 11. fusion - love it
I just thought that one ball could be some different shape, e.g. a square or triangle becasue it's a fusion of two different things.
12. geometry - nice, I wonder what would a simplified boost logo in a boost logo would look like for this?
Hmm, worth trying.
13. inspect - magnifying glass is frequently used for search, though I don't have an alternative idea off hand.
A magnifying glass on a Inspector Gadget's remote arm ;)
14. lock free - lock is frequently used for security, perhaps an open door?
Door means 'exit' to me. It could be something which is related to some kind of synchronization (or rather the lack of it), like disabled stop lights or opened rail-semaphore.
15. log - ok but not inspiring, perhaps there is a good way to capture streams aka arrows going into a drive, container, or that stack of cylinders that is sometimes used to represent data storage?
This is more suitable for serialization. But I can make it more complex, e.g. add a writing board.
16. MPL - I like it 17. numeric conversion - what if the arrows were made a little smaller and there was a 2.0 on one end and a 2 on the other?
Good idea! We have also Conversion (could have only arrows, probably different shape) and LexicalCast (with letters).
18. polygon - why not a simplified version of one of those nice shapes in the polygon documentation?
This supposed to be a fragment of voronoi diagram ;) Sure, we can for sure choose some picture which will look nice but it musn't be too complicated.
19. program options - this is decent, what about literally putting the text "--po" sans quotes there in the boost font? That would capture it 100% unambiguously
Sure.
20. SmartPtr - It is good 21. static assert - not as enthusiastic about this one. perhaps an exclamation mark alone or an exclamation mark with sparks aka static?
Yes, this is nice idea.
22. test - fair enough, it clicks
Also taken from the old logo ;)
23. tuple - nice, but needs to be better distinguished from variant 24. unordered - what about the numbers 1,3,2 in little boxes?
I'd also scatter them, they could look nice.
25. utility - the standard utility logo works for me 26. variant - I would change this to distinguish it from tuple, maybe a circle in a box and a triangle in a box?
Yes this probably also needs some changes. We must remember that we also have Any which is more or less similar. Well Variant is an alternative for dynamic polimorphism so maybe something related to that?
By the way what tool do you use to make those? Inkscape
If you like to play with it I can give you access to the repo. As I've said, more versions can be found in separate files. Since the final decision should be made by libraries authors/maintainers I'd like to hear what they think about it. Regards, Adam
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Adam Wulkiewicz Sent: Monday, December 16, 2013 11:16 PM To: boost@lists.boost.org Subject: Re: [boost] [git] Submodule's readme and logo
By the way what tool do you use to make those? Inkscape?
Since the final decision should be made by libraries authors/maintainers I'd like to hear what
In the future, it might be nice if enough instructions were available so that library authors could play with their own, starting with a plain 'template' and using Inkscape? they think about it. Nice. Discrete. Clear Boost branding. How about a logo for the Boost.Math library? And Boost.Multiprecision? Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
Paul A. Bristow wrote:
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Adam Wulkiewicz Sent: Monday, December 16, 2013 11:16 PM To: boost@lists.boost.org Subject: Re: [boost] [git] Submodule's readme and logo
By the way what tool do you use to make those? Inkscape? In the future, it might be nice if enough instructions were available so that library authors could play with their own, starting with a plain 'template' and using Inkscape?
You may just copy any of the SVG, open it in program handling vector graphics like Inkscape or Adobe Ilustrator, remove the library-specific part and you're free to go.
Since the final decision should be made by libraries authors/maintainers I'd like to hear what they think about it.
Nice. Discrete. Clear Boost branding.
How about a logo for the Boost.Math library? And Boost.Multiprecision?
Do you have some ideas/preferences? For Math I'd put some symbols like: - sum/big sigma - integral, definite integral or contour integral - differential operator or nabla - +Bi - plus big beta and imaginary (quaterions, octonions) - big gamma/gamma function or zeta funcion (special functions) Or graphics: - gaussian bell curve (statistics) - other function/curve e.g. erf(z), some polynomial(s) (special functions) For Multiprecision: - a nice simple fraction a/b or x/y, one above the other Regards, Adam
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Adam Wulkiewicz Sent: Tuesday, December 17, 2013 12:29 PM To: boost@lists.boost.org Subject: Re: [boost] [git] Submodule's readme and logo
Paul A. Bristow wrote:
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Adam Wulkiewicz Sent: Monday, December 16, 2013 11:16 PM To: boost@lists.boost.org Subject: Re: [boost] [git] Submodule's readme and logo
By the way what tool do you use to make those? Inkscape? In the future, it might be nice if enough instructions were available so that library authors could play with their own, starting with a plain 'template' and using Inkscape?
Would a few lines and an example on the wiki encourage this?. (Otherwise you may have a job for life!)
You may just copy any of the SVG, open it in program handling vector graphics like Inkscape or Adobe Ilustrator, remove the library-specific part and you're free to go.
Since the final decision should be made by libraries authors/maintainers I'd like to hear what they think about it.
Nice. Discrete. Clear Boost branding.
How about a logo for the Boost.Math library? And Boost.Multiprecision?
Do you have some ideas/preferences?
For Math I'd put some symbols like: - sum/big sigma
pi and big sigma look sorta mathy? And easy to do. Or continued fractions (since this features quite a bit in John's implementation)? See Boost Math Toolkit bmp attached. (I think I may have an svg used to create this somewhere).
- integral, definite integral or contour integral - differential operator or nabla - +Bi - plus big beta and imaginary (quaterions, octonions) - big gamma/gamma function or zeta funcion (special functions) Or graphics: - gaussian bell curve (statistics) - other function/curve e.g. erf(z), some polynomial(s) (special functions)
For Multiprecision: - a nice simple fraction a/b or x/y, one above the other
Possible but the main feature is loads (and loads) or digits, so perhaps loads of digits? Paul PS But are we getting ahead of ourselves here? Although it is a bit of a bikeshed issue, I think we should start a new thread to get general agreement on the principle of having a separate customised Boost logo for each library. --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
Hi, Paul A. Bristow wrote:
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Adam Wulkiewicz Sent: Tuesday, December 17, 2013 12:29 PM To: boost@lists.boost.org Subject: Re: [boost] [git] Submodule's readme and logo
Paul A. Bristow wrote:
In the future, it might be nice if enough instructions were available so that library authors could play with their own, starting with a plain 'template' and using
Inkscape?
Would a few lines and an example on the wiki encourage this?.
(Otherwise you may have a job for life!)
Sorry, I thought it was obvious how to edit vector graphics. I've added some info in the readme. <snip>
they think about it.
Nice. Discrete. Clear Boost branding.
How about a logo for the Boost.Math library? And Boost.Multiprecision? Do you have some ideas/preferences?
For Math I'd put some symbols like: - sum/big sigma pi and big sigma look sorta mathy? And easy to do.
Or continued fractions (since this features quite a bit in John's implementation)? This probably won't fit nicely into the small hexagon.
See Boost Math Toolkit bmp attached. (I think I may have an svg used to create this somewhere).
- integral, definite integral or contour integral - differential operator or nabla - +Bi - plus big beta and imaginary (quaterions, octonions) - big gamma/gamma function or zeta funcion (special functions) Or graphics: - gaussian bell curve (statistics) - other function/curve e.g. erf(z), some polynomial(s) (special functions)
For Multiprecision: - a nice simple fraction a/b or x/y, one above the other Possible but the main feature is loads (and loads) or digits, so perhaps loads of digits? Loads?
Paul
PS But are we getting ahead of ourselves here? Although it is a bit of a bikeshed issue, I think we should start a new thread to get general agreement on the principle of having a separate customised Boost logo for each library.
Yes that's probably a good idea, now when we have something to show to prove it's possible to make a quite consistent set ;). However the number of people talking about it in this thread isn't too big and I assume that it will be the same in different thread. I also suspect that at the end the libraries authors will do whatever suits them but I hope that at least some of the logos will be used. Regards, Adam
Hi, Paul A. Bristow wrote:
PS But are we getting ahead of ourselves here? Although it is a bit of a bikeshed issue, I think we should start a new thread to get general agreement on the principle of having a separate customised Boost logo for each library.
In case you didn't follow the thread about the readme. I thought it would be good for the Boost brand if libraries logos were more consistent (in style) than it's now (https://svn.boost.org/trac/boost/wiki/LibrariesLogos). Those new logos should be: - minimalistic and have clean, Boost-like style, - clearly connected with Boost, - created for a bigger number of libraries. I've decided to use Boost logo as a base and to add a small, white abstraction representing the library, in the lower-left hexagon. This way, they're also consistent with the original Boost logo in the case if someone wanted to use it instead. You can find logos here: https://github.com/awulkiew/boost-logos. The example set is also presented in the README (at the bottom of the page). What do you think about this idea? Regards, Adam
On 13 Dec 2013 at 12:23, Adam Wulkiewicz wrote:
What I'd suggest is to create README.{md|markdown} file in root directory of geometry repo: have big heading on top [snip] Let me know what do you think about it. And don't hesitate to write about your ideas or propose changes.
AFIO has this Readme: https://github.com/BoostGSoC/boost.afio It's very terse, only containing a link to the most recent buildbotted Boost docs and a per-target matrix of build and unit test pass/fail results for master branch with red and green colour coding. I think we ought to strongly encourage such live matrices of automated testing dashboards in Boost, and the github Readme is a very good place to put it. Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
On 16 December 2013 01:17, Niall Douglas <s_sourceforge@nedprod.com> wrote:
On 13 Dec 2013 at 12:23, Adam Wulkiewicz wrote:
What I'd suggest is to create README.{md|markdown} file in root directory of geometry repo: have big heading on top [snip] Let me know what do you think about it. And don't hesitate to write about your ideas or propose changes.
AFIO has this Readme: https://github.com/BoostGSoC/boost.afio
It's very terse, only containing a link to the most recent buildbotted Boost docs and a per-target matrix of build and unit test pass/fail results for master branch with red and green colour coding.
I think we ought to strongly encourage such live matrices of automated testing dashboards in Boost, and the github Readme is a very good place to put it.
The build matrix is an great idea. Best regards, -- Mateusz Łoskot, http://mateusz.loskot.net
2013/12/13 Adam Wulkiewicz <adam.wulkiewicz@gmail.com>
Hi,
In Boost.Geometry we recently added a readme file (currently only in develop branch http://github.com/boostorg/geometry/tree/develop) and some basic wiki.
From one of the discussions (by Mateusz Loskot):
What I'd suggest is to create README.{md|markdown} file in root directory of geometry repo: have big heading on top
[LOGO] Boost.Geometry
The readme could also explain briefly what's around, what is include folder, what is example, test folder. and link to the main documentation and wiki pages.
I was thinking about exactly the same. README.md will help some of the users.
Furthermore the style of those files could be more or less unified. Therefore I've prepared semi-consistent set of logos for some of the libraries: http://github.com/awulkiew/boost-logos. I decided to achieve the consistency by using the Boost logo as a base.
Let me know what do you think about it. And don't hesitate to write about your ideas or propose changes.
Logos are great, I like them! I'd like to have some default logo for libraries too. It can be used by libraries that have no specialized logo. -- Best regards, Antony Polukhin
participants (11)
-
Adam Wulkiewicz -
Andrew Hundt -
Andrey Semashev -
Antony Polukhin -
Beman Dawes -
Daniel James -
Mateusz Loskot -
Niall Douglas -
Paul A. Bristow -
Robert Kawulak -
Vladimir Prus