- Modules to consider
- Filter By Node Type - backup - Auto Time Zone - Path Auto - Advanced Contact - Persistent Login - Re: Comment subjects --- implemented - Revision tags - Signature - Simple Karma - Site Documentation - Taxonomy Menu - Syndication - Google Ajax Search Module - Views
- Theme issues
- UTF-8 Encoding * class="submitted" display of long dash - Headlines: fyi: wiki 3 equal signs (=) is h4, 2 equals is h5, and I guess 'h6' is one equal. Page titles are h2. - Some menus have submenus (About) that aren't expanded by default. Theme doesn't represent this. Expanded by default is controlled by the parent menu item settings. The display of the unexpanded menu needs a method similar to the Garland theme to indicate that the item displayed has sub items under it. - Comment formatting: - White space between main body and comment. - Borders around each comment?
- Drupal issues
- Authorize h4, h5 and h6 as html elements - wiki links aren't automatic (and goes to "Page not found" and not create content). Work needs to be completed to make this happen properly. I would like to see the form go to a content input form with the title filled in. Drupal style PHP coding to allow this may need to be accomplished if a module doesn't already exist. - Number of reads on bottom of the page is unneeded. - DokuWiki doesn't allow unnamed, unordered lists (currently enabled in static pages html) that is <dd> <dl> tags. - Need to apply patch http://drupal.org/files/issues/t_6.patch to help prevent data from being submitted more than once. - Recent Comments timestamps display different times with differing permissions. - Revisions, I've noticed that revisions are not always accurate. It would be nice to have the ability to highlight the differences. - "Preview trimmed version" is awful and confusing (at least to me: JL); could it be removed?
- Missing functionality
- Archive search form
- RSS integration with SF
- News - Download files * Special themeing? * Reformatting?
- Moving the cms up one path node.
- Empty the www_cache_filter table - Modify the interwiki path for mingw and mingwiki to remove the cms - Check the www_system table * may have paths to modules with the cms node embedded * may need to just empty it - Check the www_variables table * may have paths with the cms node embedded * may have to modify the table row or find the module that created the row and use the UI to change it. * MinGWiki input format->configure->Path of PEAR packages. - Change the caching level from None to Normal. Avoid Advanced like it was the death plague.
- Done deeds
- Set "About" And "MingWiki" in auto-expanded mode otherwise it's confusing as it doesn't appear to have subitems. - I (Earnie) unset the auto-expanded. I want the template to put a tick mark on the menu items with subitems. See the Garland theme for reference.
Re: Drupal on MinGW TODO
Someone on the mingw mailing list said to add comments here, I think, so here goes:
- The Mingw.org header wastes an awful lot of space for almost no information.
- The Most Recent list seems to only use a tiny central section of the screen, and I don't see how to adjust it to show more entries; I'd turn it up at least to use the available screen space, and heck, I usually turn up Most Recent entries to be several pages, because then I can just scroll through them.
- I miss the History button that wikipedia has. I found some pages have a Revisions tab, and some pages have a Track tab, I think -- is one of these a rewording of "History"?
- Those huge pictures next to each comment seem to waste a fair amount of vertical space, and they don't seem to be clickable? Shouldn't you be able to click them to see the person's home page, and to see the history of comments of that person? As to vertical space, I'd suggest it would be more efficient not to waste the four or five rows just for the image, but to let the text flow next to the image.
- What are the little black boxes before each commenter's name? I believe the HTTP response, and the embedded page metatag, both say UTF-8. When I copy & paste those funny characters and save as UCS-2, I see 0xFD 0xFF, which I don't understand. (But, I'm not sure if I trashed the text during that copy & paste operation.) Whoa, when I save the html page, those appear to be 0 bytes! Eg: (offset c. x60f0) 0x3E 0x32 0x30 0x37 0x2C 0x20 0x4D 0x61 0x79 0x20 0x33 0x20 0x2D 0x20 0x31 0x36 0x3A 0x31 0x38 0x20 0x00 0x00 0x00 0x20
Re: Drupal on MinGW TODO
It was I who invited you to comment here. Thanks for taking the time to do so.
If you peruse the comments already posted, you will see that most of your questions have already been addressed, although the associated issues may not yet have been resolved:--
- Size of header: theme designer has been asked to consider ways to reduce it. - Avatars taking too much space: we haven't definitely decided whether to keep them or not; we like the element of personalisation they provide, so it is likely they will stay. I've already requested that text be flowed around them, to reduce wasted space. - Avatars clickable, linked to poster's home page: this is a new idea, thanks. But what if the poster doesn't have one? I don't, and certainly do not have the time to either create or maintain one. - Black boxes before poster's name: already discussed, under heading `Encoding issue?' Looks like you are seeing the same effect as I do, with FireFox-1.5 on GNU/Linux. Others see a different effect. It's an issue the theme designer needs to address. - History vs. Revisions vs. Track: another new question. I think `Revisions' is most like a `History' feature; it displays the revision history for the page. `Track' seems to be more of a facility for monitoring the level of interest in a page, by counting visitors. - Length of `Most Recent' list: do you mean the page accessed from the `Recent posts' menu item, or the `Recent comments' list? I believe both should be configurable. Another issue for the theme designer to consider, perhaps.
Re: Drupal on MinGW TODO
Avatar linked to the user profile is what Drupal is capable of. There are modules for advanced user profile fields we could consider. Drupal profile design is such that the user is control of how much of the content he is willing to display to others.
Tracking I'm not sure is useful to many, I may turn access to tracking off for most users. It tracks the referer to the page.
Revisions is a history of the changes so that a revision may be reverted to the previous version.
Recent Comments is currently configured to list 10 comments. The comments are not specific to the title of the posting; i.e. it lists any comment entered on any page that allows comments to be entered. I would like to see theme changed so that font of the comment subject is smaller and the font of the comment age is smaller than the comment subject.
Re: Drupal on MinGW TODO
I had set the 'about' and 'mingwiki' to be automatically expanded; I guess someone didn't like this. I'ld like to know why... Since we don't show bullets or icons on the menu list, it doesn't seem like there's any sub content unless they're expanded by default.
Re: Drupal on MinGW TODO
It was Earnie who reset it; he did post a comment explaining why, (under the `Done Deeds' item).
If you set these to be automatically expanded, then the nav panel becomes unwieldy. It's not nice to not be able to see that these items have sub-menus, but automatically expanding them is not the solution we want to adopt; we want to use a technique, similar to that of the Garland theme, where an expansion widget appears by those menu items.
By keeping the auto-expansion feature `off', Earnie is raising the profile of this issue, encouraging us to seek an early implementation of the preferred solution. FWIW, I agree with him on the ultimate objective, but I can see a short term case for keeping these menus expanded, until that objective can be realised.
Re: Drupal on MinGW TODO
I also see a third implementation that would require javascript and act like a popup menu. But the easiest is by far a simple change to css to be more 'garland' like. I'll do some changes to the css that I'm working on. Btw, after contacting Jason, we've agreed that he'll validate it, maybe tweak it if needed, and merge the css depending on his choices/changes.
Drupal Issues Item 5
I've applied the patch http://drupal.org/files/issues/t_6.patch to prevent multiple form submissions. Now I don't need to go delete duplicate posts because the system gets slow and the users are impatient.
Second thoughts on DokuWiki vs MediaWiki formats
I can switch to [formatting]. After some playing with it I think I like it better. Let me know what you think.
I can create a different input filter to play with if we are undecided enough. Then you can choose your format. We would choose one or the other before going to production.
Re: Second thoughts on DokuWiki vs MediaWiki formats
What do you think? Should I make MediaWiki formatting the default for now?
Re: Second thoughts on DokuWiki vs MediaWiki formats
I think so. Julien has more experience of creating Wiki content than I do, and he appears to favour it. No one else has expressed any opinion.
Re: Second thoughts on DokuWiki vs MediaWiki formats
Sometime last Friday this was done. MediaWiki is now the default input format.
Re: Second thoughts on DokuWiki vs MediaWiki formats
You may now choose an ``input filter'' to try out the MediaWiki syntax filter. Once we decide I'll turn off the ability to use the one we didn't choose.
Re: Second thoughts on DokuWiki vs MediaWiki formats
For grins I converted MinGWiki to MediaWiki syntax. Notice that the URL changes from freelinking/what+ever to wiki/what_ever. Pages created already are not lost, they just need to be converted.
Re: Second thoughts on DokuWiki vs MediaWiki formats
It does look more capable; well worth playing with, I think.
Re: Second thoughts on DokuWiki vs MediaWiki formats
My thoughts on why we should prefer MediaWiki: * Wikipedia uses it, so it's probably more known to users than DokuWiki * Templates are possible (at least with a full MediaWiki distribution) * It would rock my world as you all know where I stand on MediaWiki ;-) * If there's also the javascript toolbar with such a plugin, it's even easier to write pages without knowing anything about wiki syntax. * As said, it's more capable. It's also probably more developed and tested.
Re: Second thoughts on DokuWiki vs MediaWiki formats
Well it is just a syntax filter based on the PEAR Text/Wiki not the full blown MediaWiki. As for the toolbars to enter the formatting; there are some for Drupal. I have tried a couple but the can of worms tends to rot quickly with concerns for XSS and other things. I'm content without the toolbars for now. We might consider them after we go live in phase two.
Re: Drupal on MinGW TODO [CSS]
I've modified some CSS, currently some link colors, some menu issues, and will next look into the comments section that looks poor on mingw theme. Sample of pages: http://www.amanitamuscaria.org/cms/index.html (note: this is not a drupal, just some html downloads of some pages.) Current CSS I'm using for the mingw theme: http://www.amanitamuscaria.org/cms/themes/mingw/style.css Diff on the fly of this site's style.css and mine: http://www.amanitamuscaria.org/cms/themes/mingw/diff.php
Re: Drupal on MinGW TODO [CSS]
Black on dark again! Work with Jason; he is the template designer.
Re: Drupal on MinGW TODO [CSS]
Is Jason reading this? I haven't yet seen any evidence of his participation here.
Tuomo Latto has posted these comments, on the MinGW-users mailing list:--
- In Opera using 1280x1024, the header is fairly massive. At smaller resolutions it must look HUGE. - The comment section needs some sort of visual breaks to separate the comments from each other.
Prompted by this, and having QuickRes installed on this Woe32 box, I've made the following observations:--
^ Browser: | FireFox 2.0.0.3 | ^ ^ Visible Display Height: | 27.2cm |
^ Resolution ^ Toolbar Height ^ Header Height ^ Content Height ^ | 800x600 | 8.5cm (31.25%) | 9.3cm (34.19%) | 9.4cm (34.56%) | | 1024x768 | 6.7cm (24.63%) | 7.3cm (26.84%) | 13.2cm (48.53%) | | 1280x1024 | 5.2cm (19.12%) | 5.0cm (18.38%) | 17.0cm (62.50%) | | | Notes:-- - All measurements taken with FireFox window maximised. - `Toolbar Height' is aggregate of FireFox tool/menu/status bars plus Woe32 taskbar. - `Content Height' is with header fully visible in the maximised window display.
Since Tuomo's is the second comment we've had about the relative size of various page elements, and in particular the space occupied by the header, perhaps we should give some thought to shaving off some of it's height; perhaps:-- - Raise the green block closer, (all the way?), to the top of the page. - Move the text `Minimilast GNU for Windows' slightly to the right, and up, keeping it closer to the `MinGW.org' logo. - Reduce the vertical space between the logo and the tabbed links. - Shave off some of the top and bottom margins, within the green panel.
While I don't think that, at just under 20% of available height, the current layout is too bad, (10% would be better), I do tend to agree that filling in excess of 1/3 of the available display height, (and >50% of the browser window), at lower resolution isn't so nice.
I also fully agree with Tuomo's second point, although I believe that's already an identified TODO issue.
Re: Drupal on MinGW TODO [CSS]
Oops! What's happened to my carefully laid out table of observations? And the itemised lists? Both were entered using DokuWiki syntax, and it looked fine yesterday, but it seems to no longer apply to this comment.
And then, all of a sudden, as if by magic, it's working again!
Re: Drupal on MinGW TODO [CSS]
I sent Jason email to make sure he is aware. He was last logged in more than a week ago.
Re: Drupal on MinGW TODO [CSS]
Adjusting the size of the logo might help as well. The ``Minimalist GNU for Windows'' slogan could be displayed to the right of the logo instead of under it.
Links to external addresses
I have installed a module to set target="_blank" for any link that points to an external site. This currently is only working for links within the static pages. I hope to see it working for the wiki pages soon.
Re: Links to external addresses
Maybe we should add
to our template and not use the links module. Then we would eliminate a table and sql queries for every page. Comments?
Re: Links to external addresses
I've added this script to the page.tpl.php file. However, rather than _blank I've given a named target of _mingw_external so that only one extra page is opened.
Re: Links to external addresses
Does the above script work in the wiki world?
Re: Links to external addresses
I've tested the script at the end of the page.tpl.php file for the garland theme elsewhere. It worked just great. The concern someone else I was speaking to about the script is that it may not be able to determine that href="/my/path/to/somefile.php" is internal. I don't think we need to be concerned with it.
Re: Links to external addresses
I think the javascript is the best method since it's the easiest to put into place and there's nothing to maintain.
Page namespace
I am thinking that for the HOWTO and FAQ pages we should namespace them by prefixing howto: or faq: as appropriate to the page titles. Comments?
Re: Page namespace
In the case of HOWTOs, it's common practice, if not even mandatory, to have the word `HOWTO' as the first in the page heading, and in the HOWTO catalogue, I've adopted that practice in the link names. However, I do note that the actual page names don't follow any such convention, so perhaps this makes sense.
For the FAQ, are we planning to subdivide it? If it remains as a single page, as on the present MinGWiki, the obvious page name is FAQ, and faq:FAQ seems rather redundant. If we subdivide it, then again it makes sense to use a `faq:' prefix on the supplementary page names, or at least, to include `faq' somewhere in each page name.
Re: Page namespace
The FAQ though is already subdivided with sub-pages linked within the form. I am thinking we should make use of the Drupal power and break each question into its own page. The menu item for the FAQ would naturally be the question.
The FAQ page itself would contain an explaination of a FAQ and what is appropriate to add as a FAQ entry.
Re: Page namespace
So, you would like to abandon the traditional Q&A style for a FAQ? Make each question a menu item? And each answer a separate linked page? It could work, but I'm not sure that I like it. To me, FAQ implies a (possibly long) list of questions, interleaved with short answers; only if a question merits a relatively long answer, does that merit a link to a separate page, IMO. If you give each answer a separate page, a lot of those pages are going to look empty and forlorn.
FWIW, I'm not particularly enthusiastic about the use of an unordered list, as we currently have with phpwiki on the existing MinGWiki, as a container for the FAQ. IMO, a more appropriate container would be HTML's definitions list, which didn't appear to be supported in a satisfactory manner in phpwiki, and is conspicuously absent from the set of list types supported by dokuwiki.
Re: Page namespace
Term and definition lists can be emulated with row header as the term and the next cell being the definition. I used this with the MinGWiki page.
My thought for individual pages for each question for the FAQ would lend toward a comment being posted specific to the question. If we use one page for the FAQ I would suggest disabling comments for that page but controlling it remaining off isn't doable since all authenticated users would be able to edit that function.
Re: Page namespace
I'll confess, I hadn't thought of users adding comments to FAQ entries. That would tend to make it a discussion forum, rather than a FAQ in the traditional sense. Nevertheless, it could be a worthwhile idea. What a pity only we two seem to be contributing to this discussion, for other opinions would be useful here.
Re: Page namespace
Thanks, Earnie for the email about this forum. I appreciated finding it in my email box. Now, on to the FAQ vs. HOWTO question.
I do not know enough about Drupal or its structure to comment on how to actually to code the thing. That being said, I can only offer a more generic suggestion re: the actual format as it is seen here.
I do agree that a more compartmentalized list would be more user friendly. An example would be in order here I think.
From Mingw.org wiki:
* What is MinGW? * What is MSYS? * What is w32api? * Where can I get MinGW? * How is MinGW licensed? * What is the current version? * Can I use older versions? * What Languages Are Supported? * Why are C++ programs so large? * How do I execute configure scripts? * How do I use MinGW with MSYS? * How do I use MinGW with Cygwin? * Is support provided for COM? * How can an MSVC program call a MinGW DLL, and vice versa? * How can a JNI DLL be created? * How can I build a cross compiler? * What's the difference between gcc.exe and mingw32-gcc.exe? * What is a Makefile and how do I create one? * Why is make named mingw32-make.exe? * How to remove DOS command windows? * How can I report bugs? --- I would suggest categorizing/compartmentalizing the faq as follows: Mingw/MSYS Frequently Asked Questions
Mingw What is MinGW? Where can I get Mingw? How is MinGW licensed? What is the current version? Can I use older versions? How do I use MinGW with MSYS? How do I use MinGW with Cygwin?
Msys What is MSYS? ... ...
Hopefully that gives everyone a better sense of what I am suggesting as a format for the FAQ here.
Re: Page namespace
Emulating a definitions list with a table doesn't quite work, IMO:
^ Q. ^ What is MinGW? ^ | A. | A collection of freely available and freely distributable Windows specific header files and import libraries, augmenting the GNU Compiler Collection, (GCC), and its associated tools, (GNU binutils). See the description on our Home Page. |
^ Q. ^ ... and MSYS? ^ | A. | A Minimal SYStem, providing a POSIX compatible shell environment, and a few UNIX tools, to facilitate execution of the configure scripts and makefiles used to build Open Source software. It is also suitable as a general purpose replacement for cmd.exe, for those who prefer a UNIX shell. |
Notice how the `A.' tag for the answer doesn't align to create the desired hanging paragraph layout, and the horizontal rules separating the table rows rather detract from the effect. Even as a table, it fails, for there are no vertical rules separating the columns.
I also notice that the dokuwiki syntax for laying out a table conflicts with the use of `|' within a reference, for specification of a link name. Yuk!
Re: Page namespace
What if you remove Q and A cells?
^ What is MinGW? | A collection of freely available and freely distributable Windows specific header files and import libraries, augmenting the GNU Compiler Collection, (GCC), and its associated tools, (GNU binutils). See the description on our Home Page. |
^ ... and MSYS? | A Minimal SYStem, providing a POSIX compatible shell environment, and a few UNIX tools, to facilitate execution of the configure scripts and makefiles used to build Open Source software. It is also suitable as a general purpose replacement for cmd.exe, for those who prefer a UNIX shell. |
Re: Page namespace
This works quite well, provided the text of the questions is kept short and snappy; not sure that it would scale well for longer questions, though.
It would look better if the rule at the bottom of the table spanned the full width of the table, rather than stopping short after the first column; why does it do that? Furthermore, what controls the width of the columns? I notice that even in this minimal example, they aren't consistent between the two rows; this detracts from the overall effect, IMO.
Re: Page namespace
I'm not sure. We may be able to adjust with the template coding.
Re: Page namespace
FWIW, I like this layout. To Keith's point, it doesn't follow the 'traditional' FAQ layout, but I don't see that as a big deal. To me this is more visually appealing. FAQ's are traditionally text-only, so if we can jazz them up a bit using doku syntax, why don't we?
Re: Page namespace
Contrast the above with a definitions list, laid out using HTML:
This is closer to the traditional FAQ layout; indeed, if the style sheet could be tweaked to actually honour the `float:left' setting I wanted for dt elements within a dl of class `faq', the `font-weight:bold' for class `Q' elements within this same dl class, and with some tweaking of the vertical spacing of the list elements:
<style type="text/css"> <!-- dl.faq dt { float: left } dl.faq .Q { padding-top: 15px; font-weight: bold } dl.faq .A { padding-top: 5px } --> </style>it would exactly fit this traditional layout model. (And BTW, why did I need those entities within the <pre>...</pre> block I used to wrap this sample stylesheet snippet? I thought that was supposed to preserve whitespace, but it doesn't seem to here!)
Re: Page namespace
I have seen the issue of preservation of white space brought up before on the Drupal lists I watch. We'll probably have to code our own filters to make it do as we want. The mix'n'match seems to have limited ability and the order (`weight' in Drupal speak) of which filter is applied first is important.
Re: Page namespace
Answering my own question here: on examining the page source, I see that the `<pre>...</pre>' tags I'd inserted were removed, presumably by your HTML filtering code.
I appreciate that we do need this filtering, to remove potentially harmful tags, but is `<pre>' one of those? I also note that a `<style>' element that I'd added was removed; that one probably is a reasonable candidate for such filtering, to avoid possible corruption of the site style.
Re: Page namespace
Probably, ok. The dokuwiki syntax uses `< code>' and `< ?php>'. I'll see what I can do with mixing syntax filters. I can add tags to ignore in the wiki filter but I haven't tried that yet.
Re: Page namespace
Looks like I have some success with mixing filters. I'm sure more configuration is likely to be needed to get the full set we desire. Your <pre> tags are now available in the output.
BTW, there is an unplanned feature that caches the filter results in a {cache_filter} table that needs to be truncated/emptied before the changed filter will take effect. I consider this a bug in Drupal since I have the cache level set to none. When I get more time I'll take a look at the current CVS which will freeze feature enhancement the first of June to see if the problem still exists.
Re: Page namespace
I have concluded that mix'n'match doesn't work together well. We'll have to recode the wiki filter to do what we want. Perhaps MediaWiki filter syntax would be a better fit? I'll take a look at that.
Avatars
Do we want them?
Re: Avatars
I'm undecided on this. On the one hand, it is nice to see an image of those which whom we are corresponding; on the other, they do occupy quite a bit of vertical space, when they are attached to every posting. If people can be trusted to use them for genuine photo images of themselves, then perhaps there is a case for using them; if they start sticking in purely symbolic icons, then I'd say not.
Maybe a `rogues gallery' of site contributors, with photos and mini curriculum vitae, would be a better choice.
Re: Avatars
Take a look at the use of avatars on groups.drupal.org. I think it gives personality to the site and helps you to visualize who wrote it. I currently only have them enabled for comments but they can be enabled per content (node) type. You can see on groups.drupal.org that theming helps with the display of the avatar.
Re: Avatars
I don't dispute that the added personalisation is a nice touch, if it's restricted to actual photo images of the user. What I dislike is the use, that I've seem on some fora, of purely symbolic icons; to me that conveys nothing, beyond perhaps an impression that the user is ashamed of his/her own appearance.
Now, if we could have the text flowing around the right side of the avatar, as it does on groups.drupal.org, then we would lose that blank looking area; that would be an improvement, IMO. Another theme tweak, I guess.