Athens Release
Released as TWikiRelease01Dec2001
Next Release codenamed BeijingRelease
Introduction
Athens is the code name for release that came out in 01 Dec 2001
To-Do
List of features and fixes that should go into the Athens Release. The
CoreTeam should update this list.
"Nice to Have" List
All: Please add other features you would like to see in the Athens Release. The
CoreTeam will evaluate what is possible.
Change Proposals for AthensRelease still being worked on
Search for topics that still need work:
Change Proposals for AthensRelease Awaiting Merge
Search for topics Proposed for AthensRelease that are
waiting for merge to the MAIN branch:
Change Proposals for AthensRelease Merged to Main SVN Branch
Search for topics Proposed for AthensRelease that have been
MergedToCore or
ImplementedAsExtension:
Release State Summary
See also
AthensReleaseSummary and
AthensReleaseUpgradeGuide
Known issues
See
KnownIssuesOfTWiki01Sep2001.
Feedback and requests
Please add below.
--
PeterThoeny - 13 Nov 2001
I would like to add
RefreshEditPage as a nice to have - this is fairly significant in that it can cause a loss of edit text, the second time someone edits a page. It could be controlled by an option, but IMO should be the default since it has no negative impact and works with any browser. I've tested it quite a bit with various browsers.
The
BackFromPreviewLosesText issue is more significant, but unfortunately there is no fix for this, so all that can be done is to reference it in the docs.
--
RichardDonkin - 15 Nov 2001
Added
TopicNotFoundInThisWeb, I hope that's okay. I guess though that if this release is only bug-fixes then it shouldn't go in.
If that's the case, perhaps can we start a topic for the subsequent release that in which we can request added features?
--
MartinCleaver - 15 Nov 2001
I have just lost some editing done to a page on TWiki.org because of
RefreshEditPage! This is really annoying... Anyone who is using Opera is at high risk of losing edits through this problem - even though I'm aware of this issue, I forgot to do the Refresh on the second Edit, and thus lost the edits.
Can we please implement the fix on
RefreshEditPage in the
AthensRelease? This works fine for me with various browsers, and
ColasNahaboo has also tested it. Perhaps it should be controlled by an option for people who only use IE5 and don't want the extra characters on URLs (although this only affects the Edit URL, which should of course never be bookmarked, so the extra characters are not really an issue IMO).
Just because IE5 doesn't have this problem doesn't mean it should stay unfixed... Once this fix is in, Opera will become a good browser for TWiki use, since it doesn't suffer from
BackFromPreviewLosesText (as IE5 does).
--
RichardDonkin - 17 Nov 2001
I'd also like
WebFastIndex,
PopupPageIndexForEditing, and
ScriptToCreateNewWeb please. Gosh! I seem so demanding!
Would anyone like to second my requests?
--
MartinCleaver - 17 Nov 2001
I quite like the
PopupPageIndexForEditing, but unfortunately it may well cause the
BackFromPreviewLosesText bug on IE5, so I would prefer not to see this included until we have a good solution for that bug.
ScriptToCreateNewWeb would be nice, and presumably has little impact on the rest of TWiki.
--
RichardDonkin - 19 Nov 2001
Fair point.
How about
SaveAndContinueWorkingFromPreview?
--
MartinCleaver - 19 Nov 2001
Dunno what it involves, but it would be nice to clean up all the TWiki text formatting rules that require white spaces. I haven't started a list - can you determine which this applies to from how different markup code is handled? Some from memory:
- can't enclose Interwiki links in square brackets to make more readable links ex ... "speaking of Wiki:WardCunningham" VS "speaking of WardCunningham"
- *bold*'s - stuff like that breaks the flow of using shorthand, you gotta drop in HTML
- etc (is an individual case list needed or is this some general parsing order/rules thing?)
--
MikeMannix - 22 Nov 2001
Re:
- can't enclose Interwiki links in square brackets to make more readable links ex ... "speaking of Wiki:WardCunningham" VS "speaking of WardCunningham"
A solution to this could (might) disable the ability to see the Web using the square link syntax. (To me, seeing the Web is desirable, at least under some circumstances, for example
Wikilearn.WebHome.)
--
RandyKramer - 22 Nov 2001
I agree. There are times when the visible "path" is good, it not only indicates a remote link, but also to where. But, in other cases, it's a problem, it destroys the syntax of sentences in a more troublesome way than
WikiWords are sometimes accused of doing (which was the motivation for square brackets, to be able to separate words and write in lowercase and hide URLs). Interlinks adds words, often meaningless to the reader, with a colon that on many screens is near invisible, and doesn't intuitively suggest a
remote link in any case.
My point on TWiki shorthand - a point now splattered all over Codev; I'll have to gather it all up eventually - is:
Why half-step? TWiki has made a point of going to great lengths to create all sorts of preprocessing rules - there's no real line, unless things get out of control, too complicated. Peter just last night simplified one rule, to fix an unexpected problem - see
SimplifiedPrefixForWikiWords - because a word expanded for Ref-by got reprocessed in its expanded form into a new string and broke itself.
It would be great if TWiki notation could do
certain things seamlessly. It's already powerful, but has its blind spots. I can bold
Billy with ease, but *Billy*'s bolding can suddenly take a turn for the nonfunctional. The more that's offered, the more that's expected.
In the specific case you mention, there are all sorts of possible solutions, well within the spirit of TWiki dev: a small inline world icon (QBullets is a cool 11pt free set for this use), could pop up, indicating a remote link. Etc. But would that lead to other complications, functionally or in usuability, or both? A good, comprehensive spec for TWiki shorthand would be excellent, an arbitrary list of great capabilities, a limited set to perfect. IMHO.
--
MikeMannix - 22 Nov 2001
One admin/process comment - we should really be discussing longer-term changes elsewhere, since this
AthensRelease is primarily for bug fixes and minor features. Improving the TWiki syntax is not as minor as it appears IMO.
- SaveAndContinueWorkingFromPreview would be nice, but it's not a solution to BackFromPreviewLosesText, since many users would still hit the browser's Back button and run into this problem.
- TWiki formatting shorthand is a compromise between having powerful formatting and simple syntax - in some ways, it's already veered towards the 'power' end of the spectrum, but it is still hard to do some things. Unfortunately, I'm not sure that there is an easy solution to this without introducing more HTML-like markup. Perhaps a JavaScript or Java WYSIWYG editor would allow richer formatting by using such markup - this is probably the way to go, as it allows better formatting without decreasing usability.
- As for the Interwiki and other-web links, I think sometimes you want the full path to be shown and in some cases you want just the web name or some other text altogether. It would be great to improve the regularity of TWiki features, i.e. make sure that feature X can be applied with features A, B and C.
I am a big fan of
EasierExternalLinking, i.e. links like
[[http://www.foo.com Foo Corp]]
- this was driven by the fairly complex syntax for this in standard TWiki. However, nobody else seems to be bothered enough by this to add it to the core code
--
RichardDonkin - 26 Nov 2001
Not sure if this is a bug or if
createtopic
needs some text rearranging. When I create a topic, I see:
All Topics generally be given a
WikiWord as their name, otherwise automatic linking of topic text will not happen. Exceptions:
- All capitals (at least 3 letters) will link
- For topics in the Products Web - a single word with initial capital (at least 3 letters) will link
Neither of these rules seems to apply in the default installation (I created a "Products" web just to see). Is there an additional administrative steop I need to take to make these special rules effective?
--
DavidWeller - 03 Dec 2001
Is your createtopic template from the TWiki core or from the
TigerSkinPlugin? If the latter, it needs to be in the
TigerSkinPluginDev topic.
--
JohnRouillard - 04 Dec 2001
On
RcsNonStrictLocking (last proposal, not the first one): I suggest implementing my last fix, which consists in setting
in TWiki the env variables USER and LOGNAME that
RCS needs to properly lock topics
--
ColasNahaboo - 05 Dec 2001
Changed to
FeatureDone...finally. Maybe some of the unimplemented "Nice to Have" items should be moved forward to the
BeijingRelease, or maybe even the next one after that? I guess that should be left to parties interested in particular items to do.
--
WalterMundt - 08 Jan 2003
Sure, you are right, but I guess many of them are already in.
If you feel like tidying up, I suggest you could add sections titled 'Items brought forward to
BeijingRelease', 'Items implemented' and 'Items dropped'.
--
MartinCleaver - 09 Jan 2003