> About that TOC plugin, it seems you really didn't get it… even if we > tried to explain.
Yes, I understand it now. Apparently you and Maren and Martin can add new questions, as well as answers. But I can't add new questions - only answers, because I can't edit the code. The TOC is frustrating for me, because I originally typed/edited everything on the page (by writing the html directly, which I find enjoyable). But like so many other parts of the website cms/django, it very much limits what I am able to do. Now, except for minor edits, here and there, all I can contribute is comments about the website content. By now, most of the website is controlled from a level that I don't have access to, and couldn't use it, even if I did. > Okay, but then, how can you edit the plugins? This is the main problem. When I first created that page, the only plugin available (to me) was Links. At first, I didn't use it at all, because it didn't work. But later, we found the problem was one of my Firefox plugins that blocks the referrer header. So then, I was able to fix all the links. All best, brynn -------------------------------------------------- From: "Sylvain Chiron" <chironsylv...@orange.fr> Sent: Friday, June 03, 2016 12:27 AM To: "Brynn" <br...@frii.com> Cc: "Inkscape translators" <inkscape-transla...@lists.sourceforge.net>; "Inkscape Docs" <inkscape-docs@lists.sourceforge.net> Subject: Re: [Inkscape-docs] Questions concerning the website's content > Le 03/06/2016 à 05:45, Brynn a écrit : >> For #1, I brought this up a long time ago. Well, something very >> similar (I think it was the h3 style I wanted to tweak, or maybe >> h4.....). I think the text styling needs an overhaul....or at least a >> tweak. Styles, and maybe even some classes or IDs, etc. too. The reply >> at that time was that we were considering a new website design in the >> foreseeable future. Although it seems like it stays in the distant >> future, and doesn't get closer. But the response was let's talk about >> it when we are getting a new design. > > Sure, we could have a better design… Currently pages' content is a bit > blunt. I don't think it's the right moment as the focus is on the 0.92 > release. We could work on it in a few months if you want. > I also have other work, such as translating that FLOSS manual… > >> There's a good chance that I put most of those empty paragraphs >> in there. The pages, and especially the pages with a lot of text, come >> across as imposing -- the wall of text, as they say. So I think they >> are the best we can do currently. I would not want to remove them until >> we have a good replacement. Do you think visitors to the site recognize >> that it's an empty paragraph? I don't see how they could know the >> difference, unless maybe if they are website designers > > If they are a bit interested in style, typography or semantics like I > am, they will notice that some headings have more space above them than > others, and they will now that use of an empty paragraph to add more > space in computer writing (most probably think it's a good use). > They can also inspect the DOM (the document tree), of course. > >> Are the changes you suggest something that could be made easily? >> I'll have to refresh my html, and dig in a little bit, to understand >> specifically what you mention. In general, I understand what you're >> saying. But as far as the code itself, that's not in the front of my >> memory. > > Yes, this is a very simple change, I can commit it within one minute. > To understand what I meant, just right-click on a heading, and click the > last menu item ‘Inspect element’. The inspector should appear, showing > the document tree, and the tag/node for the heading you right-clicked > will be selected. The styles that apply to the selected node are shown > on the right. > The style property I refer to is ‘margin’. > In Firefox at least, you should see ‘main.css:line number’, indicating > the place where the rule is defined. If you click on it, you'll go to > the file. > >> If the changes can be easily inserted into the css, I'd say let's >> do it. But in this case, one change may lead to another and another. >> So maybe better to wait until everyone is focused on the new design? At >> least that's what I like to call "my simple-minded thoughts". > > I think we can just do it because I'm very focused on the > typography/semantics of the website and this is quite annoying… > >> ((We (Sylvain and I) might not have had a formal introduction. >> So just for general info.... I do not have a local installation of the >> website. The only code I know is simple html, and my understanding of >> how websites work is fairly general and non-technical. (For example, >> this caching that's been mentioned so much lately -- I only understand >> the definition of "caching" and not what happens technically with the >> server.) I can add and edit the site content, using the django wysiwyg >> and/or the source/html. And I can join discussions about the content. >> But I hardly have any understanding of the programming side, with the >> trunks and commits and all.)) > > About the commits, the wiki has some info: > http://wiki.inkscape.org/wiki/index.php/WebSite#Website_Development > Then I joined the project and submitted two things: a fix for the ‘TOC > nesting bug’ I detailed previously, and a fix in style to avoid overflow > of preformatted blocks, using a scrollbar — see e.g.: > https://inkscape.org/en/develop/debugging/ > Therefore I had such an introduction… > However I don't have a local installation of the website as the Python > scripts don't work with me (I didn't emailed Martin about it yet, I'll > do it), and I avoid using it as it is very hard to use with my ten-year > slow computer. Fortunately I can often look carefully at what I wrote > with autistic abilities, and prove its exactness. > About caching, well, if you know the English word (I've only known the > use in computing for a long time), this is it: the website server must > compute many things to have the document it finally deliver to the > visitor. To avoid redoing those same computations for each visitor who > looks at the very same page, it caches some results to deliver them > automatically, until the variables are effectively changed (in a perfect > world). I don't have many details about what is cached for the Inkscape > website but this principle is usually sufficient to understand everything. > The ‘trunk’ is usually unique — it is the main development branch for a > project. What is a branch? When we want to develop a feature, we might > break the project. The next person who want to develop can't wait for > our feature to be ready to start to develop their own one. So both > developments are started from a state of the project that is known to > work. Then we divide the development progress in two ‘branches’ and we > will ‘merge’ them when both will be ready, to get a project with two new > cool working features. Well, life with branches is much more rich and > complex, but this is the basic idea. A ‘commit’ is the process of > submitting a change to a branch. > Am I clear? > >> Maybe Martin and/or Maren can give updated and/or more technical >> answer for that? > > I should have enough… > >> For #2, I created the vast majority of what we have on the FAQ >> page today. (Well, the text anyway. It used to be straight html with >> anchors, but Martin installed a TOC plugin a few months ago. Now we can >> only edit the answers. If we need to add a new question, we have to ask >> Martin to do it.) I updated it from the old version, which I think is >> still existing in the wiki. (I made an updated version for the >> developers on the wiki too, but they apparently weren't interested in >> updating it. So it stays out of date.) Anyway, at that time, I had the >> option to have it all on one text block, or divided over 2 or more. > > Thanks for your investment in the FAQs. I followed the story of the > apparition of the TOC, don't you remember? > About that TOC plugin, it seems you really didn't get it… even if we > tried to explain. This plugin is a wonderful thing: it generates the > anchors itself from the page contents. Then the writers don't have to > mind the TOC when adding sections. You can totally add new questions to > the FAQ without any problem. The anchor will appear in the TOC. You > don't even have to set an ID to the heading (unless your heading has > exactly the same title as another one). > Just look at this script which is delivered with the website's pages: > http://bazaar.launchpad.net/~inkscape-webadmin/inkscape-web/inkscape-web/view/head:/cmsplugin_toc/static/js/cmsplugin_toc.js > Lines 22–26 say: when the document is ready, if there is a (single) > #toc, then initialise anchors. The description of the way to do it is > from line 35 to 83. Line 39 says: iterate over every heading in > .wrapper. Lines 44–54 say: pick an id for the current heading. Line 69: > add an anchor in the TOC as a list item leading to the heading. > >> For myself, it was better to have it all in one block. Most of >> the time, I worked on it locally in a text editor, and then pasted back >> in to save/publish. The text editor makes it so much easier, because it >> has the formatting, numbered lines, find/replace, etc. Ssooo much >> easier!! > > Okay, but then, how can you edit the plugins? This is the main problem. > Another thing that bothers me is the forced use of HTML entities by the > CMS in the source code. In English you mostly have simple letters so > that's not a problem, but e.g. in French you have many accented letters, > and the very frequent ‘é’ becomes é and the source code becomes > really difficult to read. There are also many apostrophs which become > '. And many different accented letters: à è ê ô î â û ë ï and > capital variants. > >> And so for myself, it's still better to have it in one block. >> And I would be happy to take on the responsibility to edit that page, if >> folks send me the info. However, on the other hand, I do understand >> that might not be the best scenario, logistically, for the project as a >> whole. So if everyone wants to break it up, I certainly would not >> object. I wonder if that can be done in a seamless way? Wouldn't there >> be a gap between blocks? > > https://inkscape.org/en/download/?edit > Do you see any gap? > -- > Sylvain ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e _______________________________________________ Inkscape-docs mailing list Inkscape-docs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-docs
