All,
Lex and I have had a little bit of off-line conversation about his document, the Build System User Guide. He suggested that I put it on the wiki.
I made a feeble attempt, and now recommend instead that, at least on a temporary basis, it be put on the geany.org website with one or more links from the wiki to the document. This is because: * the document is a fully formed, standalone HTML document * and, in that form, is not directly "pastable" into the wiki
Instead, unless I'm missing something, it would have to be copied and pasted in as plain text, and then marked up with DokuWiki markup.
Lex,
On Tuesday 17 May 2011 08:04:56 pm you wrote:
Well as Enrico says, the document should be located on the Wiki, and this is the stuff that should go on the page where it is to tell people what it is. No grabs, but then it matters less if its on the Wiki and introduced as above.
Since you are the Wiki-spurt (well you are writing a lexer for them) maybe you can create a page with the first cut of the intro and I can add the document later.
Ok, I made a simple minded attempt at putting your document on the wiki. Before I give you the link, let me tell you it is not really worth looking at or what you'd expect.
Apparently DokuWiki (if that is the wiki being used) cannot handle html markup. (Foswiki (nee TWiki), can, although it would probably choke on some of the things in your document (like the scripts and CSS).)
Thus, to really put your document "in" the wiki, it would have to be copied and pasted as plain text, then marked up with DokuWiki markup. More work than I'm willing to do immediately. Further, I don't know the DokuWiki markup (as opposed to the Foswiki markup, much of which I use every day.
So, I recommend that at first, your document not be put in the wiki, but instead be put on the geany.org website, separate from the wiki, as an HTML document, with one or more links from the wiki to the document.
Overtime, as people have an interest, they can move all or parts of the document to the wiki and (modify and) mark it up as desired.
The wiki page I started is here:
http://wiki.geany.org/documentation/programmingfeatures
The page designation (/documentation/programmingfeatures) may not fit with a more thought out scheme for the overall organization of the wiki which may be developed (by others), thus that page may get deleted or moved (and, certainly, as you will see, needs modification).
I'm sending a copy of this to the mail list to propose that your document be put on the geany.org website separate from the wiki (at least on a temporary basis).
Randy Kramer
Any comments on the documents content would be good too, thats the main reason for releasing it ATM. Even if its only lousy grammar and spelling (since Geany's spell checker isn't fixed yet, hi Enrico :-).
Am 18.05.2011 14:26, schrieb Randy Kramer:
All,
Lex and I have had a little bit of off-line conversation about his document, the Build System User Guide. He suggested that I put it on the wiki.
I made a feeble attempt, and now recommend instead that, at least on a temporary basis, it be put on the geany.org website with one or more links from the wiki to the document. This is because:
- the document is a fully formed, standalone HTML document
- and, in that form, is not directly "pastable" into the wiki
Instead, unless I'm missing something, it would have to be copied and pasted in as plain text, and then marked up with DokuWiki markup.
The sourcecode of this document looks pretty much like generated code.
<meta name="generator" content="AsciiDoc 8.6.4" />
Maybe Lex could use the original and put it into wiki as I don't think having another standalone document is making much sense when we already started to have a wiki as storing such things was the intention behind IIRC.
cheers, Frank
On 19 May 2011 00:24, Frank Lanitz frank@frank.uvena.de wrote:
Am 18.05.2011 14:26, schrieb Randy Kramer:
All,
Lex and I have had a little bit of off-line conversation about his document, the Build System User Guide. He suggested that I put it on the wiki.
I made a feeble attempt, and now recommend instead that, at least on a temporary basis, it be put on the geany.org website with one or more links from the wiki to the document. This is because: * the document is a fully formed, standalone HTML document * and, in that form, is not directly "pastable" into the wiki
Instead, unless I'm missing something, it would have to be copied and pasted in as plain text, and then marked up with DokuWiki markup.
The sourcecode of this document looks pretty much like generated code.
<meta name="generator" content="AsciiDoc 8.6.4" />
Maybe Lex could use the original and put it into wiki as I don't think having another standalone document is making much sense when we already started to have a wiki as storing such things was the intention behind IIRC.
Hi Frank
I said it was generated from asciidoc in my first post :-)
The reason for that is that it was started a long while ago when there was no mention of the wiki, I just finished it prompted by the recent misunderstandings.
It is normal for wikis to link to material in other formats, fully formed HTML, PDF etc. A quick look at the docuwiki manual (when desperate RTFM) shows that it handles lots of mime types but due to security risks HTML is disabled by default.
@Enrico, So I guess the question is how do we handle that? Do you want to have to give people HTML upload permission individually giving you more work, or do you want to keep it disabled. I can easily provide the document in PDF.
Or I can provide the source in asciidoc, if someone wants to convert it to docuwiki, but I'm unlikely to do that.
Cheers Lex
cheers, Frank _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Thu, 19 May 2011 09:45:45 +1000, Lex wrote:
On 19 May 2011 00:24, Frank Lanitz frank@frank.uvena.de wrote:
Am 18.05.2011 14:26, schrieb Randy Kramer:
All,
Lex and I have had a little bit of off-line conversation about his document, the Build System User Guide. He suggested that I put it on the wiki.
I made a feeble attempt, and now recommend instead that, at least on a temporary basis, it be put on the geany.org website with one or more links from the wiki to the document. This is because: * the document is a fully formed, standalone HTML document * and, in that form, is not directly "pastable" into the wiki
Instead, unless I'm missing something, it would have to be copied and pasted in as plain text, and then marked up with DokuWiki markup.
The sourcecode of this document looks pretty much like generated code.
<meta name="generator" content="AsciiDoc 8.6.4" />
Maybe Lex could use the original and put it into wiki as I don't think having another standalone document is making much sense when we already started to have a wiki as storing such things was the intention behind IIRC.
Hi Frank
I said it was generated from asciidoc in my first post :-)
The reason for that is that it was started a long while ago when there was no mention of the wiki, I just finished it prompted by the recent misunderstandings.
It is normal for wikis to link to material in other formats, fully formed HTML, PDF etc. A quick look at the docuwiki manual (when desperate RTFM) shows that it handles lots of mime types but due to security risks HTML is disabled by default.
@Enrico, So I guess the question is how do we handle that? Do you want to have to give people HTML upload permission individually giving you more work, or do you want to keep it disabled. I can easily provide the document in PDF.
I would like to keep embedded HTML and especially PHP code disabled in the Wiki, not only because of security reasons, also because it would cause mixing different markups in the Wiki, we already disagreed on this regarding ReST and Markdown syntax support in the Wiki, it's pretty much the same for HTML.
Or I can provide the source in asciidoc, if someone wants to convert it to docuwiki, but I'm unlikely to do that.
This is what I would prefer, so if you share the source, I'd convert it.
Regards, Enrico
I would like to keep embedded HTML and especially PHP code disabled in the Wiki, not only because of security reasons, also because it would cause mixing different markups in the Wiki, we already disagreed on this regarding ReST and Markdown syntax support in the Wiki, it's pretty much the same for HTML.
Hi Enrico,
Well this is intended as a manual not wiki pages. Text documents like this should not be unconstrained width, but as far as I can find there is no way of limiting width in Docuwiki. And its own manual is an example of how hard it is to read unconstrained width text. Imagine the Geany manual displayed with unconstrained width :-(
I'm not suggesting you enable embedded HTML, just complete documents. Or as I said I can do PDF if thats the only way of getting fixed size.
Or I can provide the source in asciidoc, if someone wants to convert it to docuwiki, but I'm unlikely to do that.
This is what I would prefer, so if you share the source, I'd convert it.
No problem if thats the end solution, but where are you going to get the time? Also lets also wait to see if anyone actually has any comments on the content :-)
Cheers Lex
PS what theme in what window manager do you use for screen captures for the manual? If possible I will use the same for the images to go in this document.
Lex,
Hi!
On Sunday 22 May 2011 07:14:20 am Lex Trotman wrote:
Well this is intended as a manual not wiki pages. Text documents like this should not be unconstrained width, but as far as I can find there is no way of limiting width in Docuwiki. And its own manual is an example of how hard it is to read unconstrained width text. Imagine the Geany manual displayed with unconstrained width :-(
I'm curious as to what you mean by unconstrained width, and what you see in your browser(s).
Let me tell you what I see in my browsers:
Iceweasel (Firefox/3.0.6 (Debian-3.0.6-1) on Debian 5.0): The behavior here is reasonably nice. The actual text of a document wraps to the width of the window (this is good, afaic). Oh, and so do the colored bars at the top and bottom (at first I didn't think they did, because of the way they are displayed in konqueror.
Konqueror (Konqueror 3.5.9 (on kde 3.5.10) on Debian 5.0): The behavior here is not as nice. The colored bars at the top and bottom of the page are of a fixed width (which probably varies based on the font and font size used??). On my main screen, the bars are about half the witdth of the screen. The text wraps to the width of those bars and does not adjust based on the width of the window.
This is sort of OK (on konqueror), because: * the text does wrap, so I don't have to scroll horizontally to view long lines of text * the width that it wraps to (for me) is reasonably comfortable for reading, and I can shrink the window to about half the width of the screen and still read complete lines without horizontal scrolling * if I shrink the window further, I have to scroll horizontally to read lines
(Just as an aside, I should point out that this is better than some web pages where I can't even scroll horizontally to read a complete line (maybe when the page is in the form of a table with columns and the text is in one of those columns). The best I can do then is copy and paste the text to a plain text editor (or, usually, open it in Firefox) to read the entire text.)
Anyway, so to me, the text is not unconstrained (by which I would mean long lines of text that don't wrap under any circumstance).
What do you see in your browser(s)? And (if it's not obvious) what do you object to?
regards, Randy Kramer
On 22 May 2011 22:31, Randy Kramer rhkramer@gmail.com wrote:
Lex,
Hi!
On Sunday 22 May 2011 07:14:20 am Lex Trotman wrote:
Well this is intended as a manual not wiki pages. Text documents like this should not be unconstrained width, but as far as I can find there is no way of limiting width in Docuwiki. And its own manual is an example of how hard it is to read unconstrained width text. Imagine the Geany manual displayed with unconstrained width :-(
I'm curious as to what you mean by unconstrained width, and what you see in your browser(s).
Hi Randy,
Quick question, which document are you displaying?
Cheers Lex
Lex,
On Sunday 22 May 2011 08:40:35 am Lex Trotman wrote:
Quick question, which document are you displaying?
I was just looking at the first page of the wiki, http://wiki.geany.org/.
There's only one line there, but it is long enough to see the wrapping behavior.
Randy Kramer
Hi Randy,
I'm curious as to what you mean by unconstrained width, and what you see in your browser(s).
Let me tell you what I see in my browsers:
Iceweasel (Firefox/3.0.6 (Debian-3.0.6-1) on Debian 5.0): The behavior here is reasonably nice. The actual text of a document wraps to the width of the window (this is good, afaic).
Text wrapping at the window width is what I mean by unconstrained, it is up to the browser how long lines are. In Firefox 3.6.17 same behavior.
But this is *not* good for users.
Document width for text contents should be limited, it should not straggle right across the page (see W3C WCAG 2.0 1.4.8 for recommendations, <80 characters and links to information on the physiology of reading long lines http://www.w3.org/TR/WCAG)
No, this time its not just me being a cranky opinionated so-and-so :-)
Konqueror (Konqueror 3.5.9 (on kde 3.5.10) on Debian 5.0): The behavior here is not as nice. The colored bars at the top and bottom of the page are of a fixed width (which probably varies based on the font and font size used??). On my main screen, the bars are about half the witdth of the screen. The text wraps to the width of those bars and does not adjust based on the width of the window.
Not sure what page you are looking at, if its the Geany wiki then it sounds broken, AFAICT there are no instructions to limit the width in the HTML.
(Just as an aside, I should point out that this is better than some web pages where I can't even scroll horizontally to read a complete line (maybe when the page is in the form of a table with columns and the text is in one of those columns). The best I can do then is copy and paste the text to a plain text editor (or, usually, open it in Firefox) to read the entire text.)
Those websites are just plain broken!!!
Anyway, so to me, the text is not unconstrained (by which I would mean long lines of text that don't wrap under any circumstance).
Wrong meaning, sorry, I mean not constrained by the HTML, specifically the max-width attribute set to <= about 40em.
Cheers Lex
Lex,
This is one of those cases where I wrote a long email because I didn't have (or didn't want to take) the time to write a short email. Sorry.
If you read the next 5 paragraphs, you'll get the gist of what I'm saying. I'd suggest you ignore the rest--consider it notes to myself.
It looks like the max width attribute is a fine thing for a page viewed in Firefox, but causes problems in konqueror 3.5.9.
It seems that konqueror treats it both as a min and a max. In other words, it fixes the line length at what is specified as the max, and, if I shrink the window width below that line length, the text will not wrap to below that length. Instead I am forced to scroll horizontally to view the entire line.
I guess someone would say konqueror 3.5.9 is broken. Someday I'd expect to upgrade to kde 4.<something> which would hopefully solve the problem.
So, I understand what you are saying now. And, if you want to put the document somewhere where the max width attribute can be specified, that's fine with me. (Because usually my browser is opened to the full width of the screen.)
OTOH, I wouldn't have a problem with your document on the wiki, because: * in konqueror (3.5.9) the text wraps to the width of the horizontal bars on the page, which, is about 78 characters according to wc * in Iceweasel, the text wraps to the the width of my browser window
I use konqueror as my default browser, with Java, Javascript, and cookies turned off. (I turn on cookies and javascript for selected pages when needed.)
If I can't successfully use a page in konqueror, I'll open it in Iceweasel.
(This is for a number of reasons, among them, Iceweasel (Firefox) doesn't (easily?) allow multiple independent instances--if I do something to make Iceweasel crash, all "instances" of iceweasel crash. (Firefox might have addressed that in the last few years.) In contrast, every instance of konqueror is a true independent instance--if one crashes, the others are not affected.)
On Sunday 22 May 2011 09:49:06 am Lex Trotman wrote:
Text wrapping at the window width is what I mean by unconstrained, it is up to the browser how long lines are. In Firefox 3.6.17 same behavior.
But this is *not* good for users.
Well, maybe it depends on what side of a line you're on--I'll have to think about what I mean by line. It is good for me, compared to some web pages that do not wrap at all with long lines, and then I have to scroll horizontally to read the end of a line.
Document width for text contents should be limited, it should not straggle right across the page (see W3C WCAG 2.0 1.4.8 for recommendations, <80 characters and links to information on the physiology of reading long lines http://www.w3.org/TR/WCAG)
I agree (very strongly) that document width should not exceed something like 60 to 80 characters (I'm agreeing with your <80). But, I'm happy to adjust that to suit myself by adjusting the width of my browser window (when necessary).
If the browser itself, or the HTML (with the max width attribute you mention set to some limit (like 40 ems?), limits the lines to reasonable lengths, so I don't have to adjust the width of my browser, that's peachy.
The two (or three) things I do not like are: * long lines that will not wrap so I have to scroll horizontally to read the entire line * web pages with text in columns that in some browsers (konqueror 3.5.9) will not wrap to the displayed width of that column, so I have to scroll horizontally within that column * even worse are the pages that won't let me horizontally scroll within that column and I have to C&P to an editor to read the text (fortunately, at least usually, the C&P, picks up the entire text even though it is not visible on my browser screen.
I guess I should experiment with the HTML max width attribute to see what it does.
Ok, I did some experimentation. Maybe (probably?) konqueror 3.5.9 is just a broken browser.
In Iceweasel, I have no problem with the max width attribute. It limits the length of the line even if the browser window is wider than that, and allows me to shorten the line by shrinking the window width to below the max width set by the max width attribute.
OTOH, in konqueror, it creates one of those behaviors that I hate. If the width of the browser is wider than the length of the line set by the max width attribute: no problem, it behaves just like Iceweasel.
However, if I try to shrink the width of the browser below that width, the line will not rewrap to fit the width of the window. Instead, the part of the line wider than the browser window is cut off, and I have to scroll horizontally to see it.
Apparently konqueror 3.5.9 treats the max width as both a min and max.
No, this time its not just me being a cranky opinionated so-and-so :-)
If you are being a cranky opinionated so-and-so, I have to claim membership in the same group. ;-)
Randy Kramer
Konqueror (Konqueror 3.5.9 (on kde 3.5.10) on Debian 5.0): The behavior here is not as nice. The colored bars at the top and bottom of the page are of a fixed width (which probably varies based on the font and font size used??). On my main screen, the bars are about half the witdth of the screen. The text wraps to the width of those bars and does not adjust based on the width of the window.
Not sure what page you are looking at, if its the Geany wiki then it sounds broken, AFAICT there are no instructions to limit the width in the HTML.
(Just as an aside, I should point out that this is better than some web pages where I can't even scroll horizontally to read a complete line (maybe when the page is in the form of a table with columns and the text is in one of those columns). The best I can do then is copy and paste the text to a plain text editor (or, usually, open it in Firefox) to read the entire text.)
Those websites are just plain broken!!!
Anyway, so to me, the text is not unconstrained (by which I would mean long lines of text that don't wrap under any circumstance).
Wrong meaning, sorry, I mean not constrained by the HTML, specifically the max-width attribute set to <= about 40em.
Cheers Lex _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On 23 May 2011 01:30, Randy Kramer rhkramer@gmail.com wrote:
Lex,
This is one of those cases where I wrote a long email because I didn't have (or didn't want to take) the time to write a short email. Sorry.
Still short of time I see :-D and you didn't answer the question of what document you were talking about, so I will specify that I'm talking about the HTML doc I posted, I know what the settings in it are.
[...]
I guess someone would say konqueror 3.5.9 is broken. Someday I'd expect to upgrade to kde 4.<something> which would hopefully solve the problem.
Time to replace your browser if it does that on my doc, thats incorrect behavior, its broken. On a current firefox it can shrink to a few characters wide and the scroll bar doesn't appear until it gets narrower than the widest single word.
So, I understand what you are saying now. And, if you want to put the document somewhere where the max width attribute can be specified, that's fine with me. (Because usually my browser is opened to the full width of the screen.)
Ditto, and it can't be resized because I have lots of tabs open and can't keep re-sizing the window each time I swap tabs.
OTOH, I wouldn't have a problem with your document on the wiki, because: * in konqueror (3.5.9) the text wraps to the width of the horizontal bars on the page, which, is about 78 characters according to wc * in Iceweasel, the text wraps to the the width of my browser window
I use konqueror as my default browser, with Java, Javascript, and cookies turned off. (I turn on cookies and javascript for selected pages when needed.)
Well that reduces the risk of the gaping security holes in such old browsers, but what a lot of trouble. I'd just upgrade.
If I can't successfully use a page in konqueror, I'll open it in Iceweasel.
And 3.0.6, thats an old version too :-)
(This is for a number of reasons, among them, Iceweasel (Firefox) doesn't (easily?) allow multiple independent instances--if I do something to make Iceweasel crash, all "instances" of iceweasel crash. (Firefox might have addressed that in the last few years.) In contrast, every instance of konqueror is a true independent instance--if one crashes, the others are not affected.)
Hmmm, I havn't had Firefox crash since I dunno when, I told you not to follow the links emailed to you by the nice Nigerian gentleman :-D
[...]
I agree (very strongly) that document width should not exceed something like 60 to 80 characters (I'm agreeing with your <80). But, I'm happy to adjust that to suit myself by adjusting the width of my browser window (when necessary).
As I said above, users having to adjust the browser window is unacceptable with tabbed browsers.
If the browser itself, or the HTML (with the max width attribute you mention set to some limit (like 40 ems?), limits the lines to reasonable lengths, so I don't have to adjust the width of my browser, that's peachy.
Yes, what I'm advocating is providing the user an orchard :-)
The two (or three) things I do not like are: * long lines that will not wrap so I have to scroll horizontally to read the entire line
Agree, browser or website broken
* web pages with text in columns that in some browsers (konqueror 3.5.9) will not wrap to the displayed width of that column, so I have to scroll horizontally within that column
ditto
* even worse are the pages that won't let me horizontally scroll within that column and I have to C&P to an editor to read the text (fortunately, at least usually, the C&P, picks up the entire text even though it is not visible on my browser screen.
Real broken.
I guess I should experiment with the HTML max width attribute to see what it does.
Ok, I did some experimentation. Maybe (probably?) konqueror 3.5.9 is just a broken browser.
Yup.
[...]
Apparently konqueror 3.5.9 treats the max width as both a min and max.
Yes, its broken, there's a theme happening here.
No, this time its not just me being a cranky opinionated so-and-so :-)
If you are being a cranky opinionated so-and-so, I have to claim membership in the same group. ;-)
Welcome :-)
Cheers Lex
Lex,
On Sunday 22 May 2011 08:02:11 pm Lex Trotman wrote:
On 23 May 2011 01:30, Randy Kramer rhkramer@gmail.com wrote:
This is one of those cases where I wrote a long email because I didn't have (or didn't want to take) the time to write a short email. Sorry.
Still short of time I see :-D and you didn't answer the question of what document you were talking about,
I thought I did, but you asked it in a separate email and I answered in a separate email. ;-) I was just using the one line content of the first page of the wiki (wiki.geany.org), but it really doesn't matter. (The one line is long enough to need wrapping, so it let me see what I needed to see. ;-)
Thanks for the further reply--I think we see things the same way. It's just that I won't upgrade konqueror (and probably not Firefox) until I upgrade my distro (Debian 5) in its entirety (to the next release).
regards, Randy Kramer
so I will specify that I'm talking about the HTML doc I posted, I know what the settings in it are.
On Sun, 22 May 2011 21:14:20 +1000, Lex wrote:
I would like to keep embedded HTML and especially PHP code disabled in the Wiki, not only because of security reasons, also because it would cause mixing different markups in the Wiki, we already disagreed on this regarding ReST and Markdown syntax support in the Wiki, it's pretty much the same for HTML.
Hi Enrico,
Well this is intended as a manual not wiki pages. Text documents like this should not be unconstrained width, but as far as I can find there is no way of limiting width in Docuwiki. And its own manual is an
Because you edit the content of the pages. The width of the rendered HTML has to be handled by the theme. We can surely use another theme for the Wiki, there is an open discussion on the Geany mailing list though except one poster, nobody made any suggestions.
example of how hard it is to read unconstrained width text. Imagine the Geany manual displayed with unconstrained width :-(
Geany's manual is a generated HTML page and the it's the same as with the Wiki: the content does not know anything of widths or other display properties. It's just the layout which defines those. For the wiki, this is the theme, for the generated manual it's the theme.
I'm not suggesting you enable embedded HTML, just complete documents. Or as I said I can do PDF if thats the only way of getting fixed size.
I don't like linking to yet another document. If you are in the Wiki, you want just information, not download and open another document. IMO this is quite distracting and unnecessarily circumstantial. I really don't want to have your great docs in a third, separate place. Either we put it into the Wiki or we put it into Geany's manual. Basically, I do think it would fit best into the manual but it would make the manual even bigger. This is why I personally would prefer the wiki, now that we have it and it just needs to get ready to use (e.g. by choosing a theme) and filled with a bit content.
Or I can provide the source in asciidoc, if someone wants to convert it to docuwiki, but I'm unlikely to do that.
This is what I would prefer, so if you share the source, I'd convert it.
No problem if thats the end solution, but where are you going to get the time? Also lets also wait to see if anyone actually has any comments on the content :-)
I don't expect it will take that much time.
PS what theme in what window manager do you use for screen captures for the manual? If possible I will use the same for the images to go in this document.
I use xfwm4 (Xfce's window manager) with my own theme. This had been discussed a few times ago already I think, that we should use a more generic theme for the manual screenshots. I don't mind much which theme and window manager to use as long as it is easy to get and dosen't look too foreign (like those weird Aqua/MacOSX themes, this is a no-go :D).
Regards, Enrico
We can surely use another theme for the Wiki, there is an open discussion on the Geany mailing list though except one poster, nobody made any suggestions.
Yes, I understand that its the theme /template, but I looked at all the themes on the Docuwiki website, and none seemed to limit the width. Maybe you will have better luck.
And as for looks, none of them seemed to be really exciting, and they are very blue?
I'm not suggesting you enable embedded HTML, just complete documents. Or as I said I can do PDF if thats the only way of getting fixed size.
I don't like linking to yet another document. If you are in the Wiki, you want just information, not download and open another document. IMO this is quite distracting and unnecessarily circumstantial.
Well I respect thats your preference, but in general I don't think its a problem, clicking on a link that goes to an HTML doc rather than a wiki page is really irrelevant to the user, it still comes up in his browser, or pdfs come up in Evince.
In fact I would say as a rough heuristic the most useful wikis are those that have details in separate docs, but that may be coincidence.
I really don't want to have your great docs in a third, separate place. Either we put it into the Wiki or we put it into Geany's manual. Basically, I do think it would fit best into the manual but it would make the manual even bigger. This is why I personally would prefer the wiki, now that we have it and it just needs to get ready to use (e.g. by choosing a theme) and filled with a bit content.
Agree it would expand the manual too much.
I don't expect it will take that much time.
You might be right, the markups are similar in concept, but of course annoyingly different in detail, and rarely suitable for global edits.
PS what theme in what window manager do you use for screen captures for the manual? If possible I will use the same for the images to go in this document.
I use xfwm4 (Xfce's window manager) with my own theme. This had been discussed a few times ago already I think, that we should use a more generic theme for the manual screenshots. I don't mind much which theme and window manager to use as long as it is easy to get and dosen't look too foreign (like those weird Aqua/MacOSX themes, this is a no-go :D).
Ok, xfce4 I can't do. As for whats a good theme, its no good asking me, I'm too lazy to change from the one that came with the distro :-D
I would just add the Gnome default to the list of no-gos Ug-gly, (IMHO).
Cheers Lex
On Mon, 23 May 2011 09:34:52 +1000, Lex wrote:
We can surely use another theme for the Wiki, there is an open discussion on the Geany mailing list though except one poster, nobody made any suggestions.
Yes, I understand that its the theme /template, but I looked at all the themes on the Docuwiki website, and none seemed to limit the width. Maybe you will have better luck.
And as for looks, none of them seemed to be really exciting, and they are very blue?
Not sure, I didn't have a close look at themes yet. As I earlier said, I don't care much about the theme. IMO it should jus look basically nice (that is, "nice" for me personally doesn't mean much, no high requirements). One thing I want to have is some kind of sidebar (or top bar) to ease navigation. I'll have a look at the themes soon, I hope.
And for the colors, nobody prevents us to overide them with something we like more :).
I'm not suggesting you enable embedded HTML, just complete documents. Or as I said I can do PDF if thats the only way of getting fixed size.
I don't like linking to yet another document. If you are in the Wiki, you want just information, not download and open another document. IMO this is quite distracting and unnecessarily circumstantial.
Well I respect thats your preference, but in general I don't think its a problem, clicking on a link that goes to an HTML doc rather than a wiki page is really irrelevant to the user, it still comes up in his browser, or pdfs come up in Evince.
I always feel quite uncomfortable when looking for information and need to open a PDF. I need to start another program, change the focus and then get back again into the browser. It just breaks the flow. A linked HTML document is not that worse but I'd say to some extend it breaks the flow also a bit at least in terms of jumping into another site, out of the wiki. That's why I'd like to keep it all at one place.
In fact I would say as a rough heuristic the most useful wikis are those that have details in separate docs, but that may be coincidence.
I can't really judge this. Didn't make this experience.
I don't expect it will take that much time.
You might be right, the markups are similar in concept, but of course annoyingly different in detail, and rarely suitable for global edits.
True but only once. The advantage is that afterwards we have the source in the wiki and not only you can change/improve it when necessary.
PS what theme in what window manager do you use for screen captures for the manual? If possible I will use the same for the images to go in this document.
I use xfwm4 (Xfce's window manager) with my own theme. This had been discussed a few times ago already I think, that we should use a more generic theme for the manual screenshots. I don't mind much which theme and window manager to use as long as it is easy to get and dosen't look too foreign (like those weird Aqua/MacOSX themes, this is a no-go :D).
Ok, xfce4 I can't do. As for whats a good theme, its no good asking me, I'm too lazy to change from the one that came with the distro :-D
I would just add the Gnome default to the list of no-gos Ug-gly, (IMHO).
As said, I don't care much. I fully do agree we should use one them but not sure which.
Regards, Enrico
I always feel quite uncomfortable when looking for information and need to open a PDF. I need to start another program, change the focus and then get back again into the browser. It just breaks the flow.
Well yes, but you need to set up your system better so it automatically opens and switches, just acts like a new window. But I know what you mean.
A linked HTML document is not that worse but I'd say to some extend it breaks the flow also a bit at least in terms of jumping into another site, out of the wiki.
I'm not sure it does if the HTML is uploaded to the wiki, same as images in the wiki.
[...]
True but only once. The advantage is that afterwards we have the source in the wiki and not only you can change/improve it when necessary.
Well thats worthwhile given how long it took to get it this far :-)
Just need to find out how to set max-width for these pages.
Cheers Lex
Am 22.05.2011 16:50, schrieb Enrico Tröger:
I don't like linking to yet another document. If you are in the Wiki, you want just information, not download and open another document. IMO this is quite distracting and unnecessarily circumstantial. I really don't want to have your great docs in a third, separate place. Either we put it into the Wiki or we put it into Geany's manual. Basically, I do think it would fit best into the manual but it would make the manual even bigger. This is why I personally would prefer the wiki, now that we have it and it just needs to get ready to use (e.g. by choosing a theme) and filled with a bit content.
I second this.
Cheers, Frank