Subject: Re: [boost] Boost Library Incubator recommended by steering committee
From: Klaim - JoÃ«l Lamotte (mjklaim_at_[hidden])
Date: 2014-06-18 15:08:05
On Wed, Jun 18, 2014 at 5:29 PM, Robert Ramey <ramey_at_[hidden]> wrote:
> Klaim - JoÃ«l Lamotte wrote
> > On Wed, Jun 18, 2014 at 6:32 AM, Robert Ramey <
> > ramey@
> > > wrote:
> >> > ps. Robert must have put some crafty code into the website - right now
> >> > it manages to reliably blow out my Firefox (-;
> Hmmm - I just went through it with firefox (on my MAC) and didn't find any
Just to clarify: that quote was not not from me.
> > By the way there is indeed a lot of problems from my pov and I was
> > thinking
> > (by experience) that if you
> > want this kind of website/application, you probably want to stay away
> > wordpress... but then you'll have to develop a bit.
> > Certainly worth it but I can't help with that so I understand the
> > Wordpress
> > choice (even if I think in the end it will be more time burnt than help).
> I touched upon alternatives in the "About" section of the website.
> Short version - I tried a bunch of them. Note: Not just considered
> or reviews - actually tried them. Nothing came close to wordpress
> in being able to produce what I wanted with the effort I had
> available. Basically I managed to get everything I wanted with
> 1000 lines of code. I don't believe any of the alternatives could
> have done that. As for being "messy" - they all are based in
> a similar combination of the tools mentioned above. Bottom line
> I just don't think any of the other alternatives would have come
> close to this.
I wouldn't have even considered the alternatives you did consider, but I
think it's because of different
backgrounds (I don't know Perl nor RVSiteBuilder and Php alone is too low
I think personally I would have gone with Django/Python, RoR/Ruby or I
would have even tried CPPCMS/C++,
but all these solutions imply a development that I guess you didn't have
the time for
so as I said I can understand going with Wordpress. Even if I think it
might be problematic on the long term/evolution of the tool.
All this is side comment of course, sorry if it don't help.
> > - the library list by category is empty for me (I see a page with header
> > and all the theme but no content);
> I added the "About this website" to explain the above. It has also
> a place for comments and discussion. My intent was that this be
> a place for gathering this type of feed back.
I am not sure I understand exactly what you mean here:
Do you mean that I should report these kinds of comments on the "About"
It's a bit "hidden" but ok if I understood correctly ok I'll do that next
> > - if I click on a library name in the alphabetical library list, I end
> > in a "Library Submission" page which have all the fields pre-filled
> > with the library information but still modifiable. It is not clear to
> > me
> > if this is a voluntary hack to display these info without having
> > to implement another page or if it is just a bug and it should have
> > been
> > another page. In any way; the "Library Submission" title
> > and the writable fields makes it seems buggy.
> It's a deliberate choice to reuse code and forms. The form is updateable
> by the author and read only for everyone else. This saved considerable
> code and I would be loath to change it. But I'm willing to entertain
> to make the intent more obvious and make it seem less buggy.
Ok then my suggestion to fix the perception with minimal efforts would be:
when the reader is not the author (read-only access to the page)
1. lock all fields in read-only mode (so that it's visible/clear and
people can't write into them at all);
2. remove the "Library Submission" title or replace it by something else
(for clarity that this page is not intended to be a library submission
form for the reader to fill)
I think these changes should be enough, but I'm not sure if it's easy to
implement from your current code.
done on the server side (where the access rights is known).
> > - having the front page text stretch all the width of the screen makes it
> > very hard to read, both because it makes too long lines
> > and because there is no space between the left and right border and the
> > text itself. This is against text ergonomic "rules"
> > and I should point that even scientific studies seem to suggest that
> > long lines makes it hard to read.
> This is my personal preference. Personally it drives me crazy to have
> he web pages not fit on browser window. This way I can just adjust
> the window to the size and shape I like and the text is (almost) layer
> out perfectly.
> Just in case, I don't believe that asking the user to change his window's
> size to read that particular website is reasonable.
> > By the way this problem is also apparent in a lot of Boost libraries
> > documentation and I do still have a hard time with reading most
> > boost doc because of this.
> again - I love the way the boost documentation adjusts to the current
> window size. I think ALL web pages should work this way. I just
> don't see anyway to reconcile these points of view.
I don't see a way either and therefore I will not argue more on this, it's
not useful a the moment.
> > In any way, thanks for the hard work; I know it's not easy to setup this
> > kind of tool correctly.
> LOL - I'm going to ignore the implication that it's currently setup
I am very sorry, I might have badly formulated my sentence: it was not my
intent at all to imply that it's incorrectly implemented or anything close,
I just meant that it's always hard to make such tool, whatever that means,
in particular when you have limited resources.
I wanted to exress my gratitude and that I wish I could help in more
(I've been in similar positions and it's not always pleasurable to have
a list of critics instead of thanks for benevolent work).