New website design
Dear fellow MacPorters, I'm taking this topic to the mailing list since not everyone is checking pull requests. We received a pull request from our first-time contributor, see https://github.com/macports/macports-www/pull/13 Please leave your feedback there. If there are no objections, I would like to see this merged, soon. Our website design is in fact desperately outdated, it probably hasn't changed since day one. (I believe the project started in 2002?) We need a complete redesign; not just changing the colour palette, but completely restructuring contents, decreasing the amount of information, adding some pictures etc. That said, I'm fully in favour of doing incremental improvements rather than waiting for the perfect solution that we might never even start implementing. Some points from a designer I talked to recently: - We have wy to many items in the menu. We should shrink that to 4 items maximum, like "download", "documentation", "contribute", ... - A small number of items could fit on top of the screen rather than the side, and it would be much easier to create responsive design. - Once we have a short list of most important items, create pictures. It could be something like a "magnified screenshot" showing a few lines of important commands, a download icon, ... - ... I also agree with the points raised in the PR: that it would be really nice to have everything in some simple markup language (ideally AsciiDoc to remain consistent), with an "edit me on github" icon in the top right corner. We don't need to do everything at once, but let's start the ball rolling ... Mojca
Re: c++ -std= strangeness
After some reading about the C++ standards, I believe that older standards do not prohibit having future-looking functions or classes in place. That said, I also find nothing regarding any such "future-looking functions or classes" in Clang [note: some people call these "extensions", like as provided by the GNU project -- and, thus requested via "-std=gnu++XY" instead of the usual "-std=c++XY". I'm investigating this issue more today, trying a list similar to what Jeff Dalton did for this GCC bug for C < https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79017 > except for C++. The good news is that we now have the legacy support project where such overlooked functions can be declared (if part of the ABI but not API), and/or defined (if not part of either the ABI or API when they should be). I believe that either can be accomplished pretty straight forwardly. We'll see & more as I find it! - MLD On Tue, Feb 5, 2019, at 12:07 AM, Joshua Root wrote: > On 2019-2-5 13:59 , Michael Dickens wrote: > > The interesting strangeness is that the clang++ compilers (both Apple and > > MP) do not generate errors when using -std=c++98 or -std=c++03 ... which is > > wrong! The #warning printout indicates that the correct __cplusplus is > > selected, but the build should not succeed! All g++ compilers correctly > > error out with these -std settings. > > > > This lack of compliance at least by default is troubling! Maybe I'm missing > > something here? Are there some other flags I should be setting to keep > > clang from figuring out the c++ standard and using it instead of what I > > specify -- if this is the issue? > > Are you certain that the C++98/03 standards prohibit the standard > library from providing this function? It may well be that an > implementation is compliant as long as everything specified in the > standard is present and behaves correctly; providing additional > functionality may be irrelevant. > > - Josh
