TiddlyWiki v2.2b5 feedback: layout/style

[FND]

Hello,

after playing around a bit with the latest beta, I thought I'd comment
on the layout/style.

Note that this should not turn into a discussion of favorite
customizations, but rather one of minor improvements relating to TW's
general appearance, or "Corporate Identity" (which is why I chose to
post this to [twdev] instead of [tw]).
Also, I'm not exactly a gifted designer, so consider yourself encouraged
to disagree!

First of all: I absolutely LOVE the #backstageArea menu, and especially
the individual panels (with dimmed background) - that really makes TW
look more like a desktop application than a website!

Now the constructive criticism (in no specific order):

* The BACKSTAGE button doesn't actually look much like a button; in
fact, it could almost be mistaken for some misplaced text.
The CLOSE button, however, looks nice (due to the uniform background).

* Tiddlers should have an unobtrusive border; I've found this to improve
readability. (Of course this also requires a bit of bottom padding.)

* I think the search bar should be moved to the top right in the header;
that'd de-clutter the sidebar while making the header look less empty.

* The header, in general, is way too tall for my taste.

* I've moved the #messageArea box to the bottom; it feels right to have
it closer to the browser's status bar, plus this prevents it from
hiding the search bar in the header (see above).

* While I like the new heading styles, they all look a bit too similar,
which makes them hard to distinguish at a glance.

A few of these suggested modifications can seen at
http://devpad.tiddlyspot.com/#StyleSheet (that's v2.1.3 of course).

I guess some of this might have been discussed before, but I think the
upcoming release of v2.2.0 is an opportune moment for reviewing these
issues (though it might actually be a bit late now... ).

-- F.

[Jeremy Ruston]

Thanks F, that's really great feedback, very much appreciated. I agree
that we're overdue a refresh of the TW design, and I'd like to do one
after 2.2.

> * The BACKSTAGE button doesn't actually look much like a button; in
> fact, it could almost be mistaken for some misplaced text.
> The CLOSE button, however, looks nice (due to the uniform background).

Check. Earlier iterations had the backstage button with a black
background, and I think you're right that the current design is too
thin.

> * Tiddlers should have an unobtrusive border; I've found this to improve
> readability. (Of course this also requires a bit of bottom padding.)

Yeah this is an interesting one. Way back with the first version I
quite deliberately avoided borders because I wanted it to feel like
the tiddlers were flowing together to form a single document. I quite
like the borders on the GTDTiddlyWiki adaptation but find, for
instance, the 'story borders' in Google Reader a bit too distracting.

> * I think the search bar should be moved to the top right in the header;
> that'd de-clutter the sidebar while making the header look less empty.

Check, good idea.

> * The header, in general, is way too tall for my taste.

Check.

> * I've moved the #messageArea box to the bottom; it feels right to have
> it closer to the browser's status bar, plus this prevents it from
> hiding the search bar in the header (see above).

Interesting, I hadn't tried that. I'm not at all happy with the
message area at the moment, and am very receptive to suggestions with
it.

> * While I like the new heading styles, they all look a bit too similar,
> which makes them hard to distinguish at a glance.

Alternative suggestions welcome.

> A few of these suggested modifications can seen at
> http://devpad.tiddlyspot.com/#StyleSheet (that's v2.1.3 of course).
>
> I guess some of this might have been discussed before, but I think the
> upcoming release of v2.2.0 is an opportune moment for reviewing these
> issues (though it might actually be a bit late now... ).

Yeah, it is. I propose to fix the backstage button issue that you
raised for 2.2, but let's defer a wider redesign until after 2.2.

Cheers

Jeremy

>
> -- F.
>
> >
>

--
Jeremy Ruston
mailto:jer...@osmosoft.com
http://www.tiddlywiki.com

[FND]

> that's really great feedback, very much appreciated.

Phew - and I had already donned my asbestos suit in anticipation of
being flamed to death with the RTFA torch...

Translation: Glad you're open to suggestions!

>> #messageArea box to the bottom [snip]

>
> Interesting, I hadn't tried that. I'm not at all happy with the
> message area at the moment, and am very receptive to suggestions with
> it.

It actually works quite well the way it is, with the new position
(though, disturbingly, I sometimes do mistake it for Thunderbird's "new
mail" notification... ).

Alternatively, maybe a horizontal bar at the bottom, kinda like an
actual status bar?
Hopefully someone else will come up with a fancy idea (like you guys did
with #backstageArea)...

>> * While I like the new heading styles, they all look a bit too similar,
>> which makes them hard to distinguish at a glance.
>
> Alternative suggestions welcome.

Well, I quite liked v2.1.3's "shaded" style (though that blue background
really did take some getting used to... ).
As you might have seen, I've kept that style for H1 (different colors
though), and then used the underlined style for H2 and H3 (though dashed
borders don't really work that well on H3). So far, that has greatly
enhanced readability for me.

Let's hand this over to the designers then; bring it on, people!

-- F.

[Simon Baird]

I agree about the border. I like to see where one tiddler ends and another begins. (But I can see the use for the opposite approach, in particular in non-linear fiction). Related is the (new in 2.2) always visible tiddler toolbar buttons. I prefered them appearing only on mouseover. I think perhaps one reason to //not// hide them is so you can see where tiddlers begin and end, which, in my view, is better done in some other way, ie a border. What about a subtle line like this: http://tiddlerbordertest.tiddlyspot.com/#GettingStarted%20StyleSheet


Simon.

[Daniel Baird]

On 23/05/07, Simon Baird <simon...@gmail.com> wrote:
> [...] Related is the (new in 2.2) always visible tiddler

> toolbar buttons. I prefered them appearing only on mouseover.

I'm annoyed by the buttons flicking into existence. I like the
tiddler buttons to always be visible, but greyed out (they can be
verrry light) when the tiddler isn't moused-over.

;D

--
Daniel Baird
http://tiddlyspot.com (free, effortless TiddlyWiki hosting)
http://danielbaird.com (TiddlyW;nks! :: Whiteboard Koala :: Blog ::
Things That Suck)

[Eric Shulman]

> > [...] Related is the (new in 2.2) always visible tiddler
> > toolbar buttons. I prefered them appearing only on mouseover.
> I'm annoyed by the buttons flicking into existence. I like the
> tiddler buttons to always be visible, but greyed out (they can be
> verrry light) when the tiddler isn't moused-over.

Both preferences are reasonable...depending upon the intended audience
for the document. In any event, it's incredibly easy to re-create the
pre-2.2 behavior with two lines of CSS:

.toolbar { visibility:hidden; }
.selected .toolbar { visibility:visible; }

-e

[FND]

> the (new in 2.2) always visible tiddler toolbar buttons.
> I prefered them appearing only on mouseover.

Actually, I quite like the always-visible toolbar.
However, the contrast between an inactive and an active tiddler's
toolbar should be more pronounced. The "active gray" is too light so it
still looks like it was just a background item.

> What about a subtle line like this:
> http://tiddlerbordertest.tiddlyspot.com/#GettingStarted%20StyleSheet

Good point; I think a line to separate the tiddler's header from its
contents is a must. (Not sure if this invalidates the need for tiddler
borders though.)

Speaking of tiddler headers: I think the subtitle should be moved
(floated) to the right of the title, right below the toolbar.

-- F.

[FND]

Since we're talking of a "wider redesign" now, I guess it should be
considered replacing the left-hand main menu with a horizontal top menu.

Each of those has its benefits (e.g. the vertical main menu can
accommodate more menu items)*, so this might be controversial.

(That's also why I posted this as a new branch of this thread, to
prevent this "poll" from diluting the rest of the discussion.)

-- F.

* except, of course, if we employed dropdown menus

[Jeremy Ruston]

> Phew - and I had already donned my asbestos suit in anticipation of
> being flamed to death with the RTFA torch...

Truly I'd like to see more of these discussions, this kind of thing is
really useful, constructive and actionable feedback. The base UI will
never be able to satisfy everyone out of the box, but that shouldn't
stop us continually reviewing and refining it.

Specific thoughts in the background include:

- the core needs to have proper support for switchable themes packed
into a single tiddler
- it would be desirable to add a new higher-level customisation layer
that allows users to make basic layout and colour changes
interactively, without editting templates or CSS

Cheers

Jeremy

[lewcid]

On May 23, 11:29 am, "Jeremy Ruston" <jeremy.rus...@gmail.com> wrote:
>
> - the core needs to have proper support for switchable themes packed
> into a single tiddler

I would love to see something like this. The lack of an efficient
distribution system is what is holding back TiddlyThemes right now.
I've got a fair few themes lying around that have not been added
simply because I cannot devise a suitable method for packaging them.
The "switchable" aspect would be "nifty"...... but the single tiddler
implementation of themes would be terrific!
Saq

[lewcid]

On May 23, 11:29 am, "Jeremy Ruston" <jeremy.rus...@gmail.com> wrote:
>

> - the core needs to have proper support for switchable themes packed
> into a single tiddler

I would love to see something like this. The lack of an efficient

[lewcid]

On May 23, 11:29 am, "Jeremy Ruston" <jeremy.rus...@gmail.com> wrote:
>

> - the core needs to have proper support for switchable themes packed
> into a single tiddler

I would love to see something like this. The lack of an efficient

[lewcid]

On May 23, 11:29 am, "Jeremy Ruston" <jeremy.rus...@gmail.com> wrote:
>

> - the core needs to have proper support for switchable themes packed
> into a single tiddler

I would love to see something like this. The lack of an efficient

[lewcid]

My apologies for the multiple posts.... it kept telling me there was
an error and the reply had not been posted!

[Simon Baird]

ooo... heresy! I can't see this going ahead (though I wouldn't mind a basic layout switcher in the core and two layouts shipped, one horizontal main menu, one vertical).

[Jeremy Ruston]

I've been wondering about the approach of having separate shadow
tiddlers for both the horizontal and vertical menus (eg, TopMenu vs.
MainMenu or something). With a bit of care, the layout should be able
to adapt to either or both of those tiddlers being empty or
non-existent.

Cheers

Jeremy

[Simon Baird]

Me too! (Weird I just mentioned this in another thread, I had no idea it was getting support in the highest places :)

I know how it can be done easily. I think I posted something like this once. Okay here goes.

Step 1.

Extend slices to be multi line capable (this would replace Udo's PartTiddlerPlugin. Syntax doesn't matter so much, but lets say:

<slice name="SomeSlice">
slice content
</slice>

(To preserve backwards compatibility, we still need the one liner slices to work)

So now you refer to a slice in the usual way, ie, this in a template works just like colors in ColorPalette:

[[SomeTiddler::SomeSlice]]

Step 2.

Now instead of reading PageLayout from the PageLayout tiddler, instead read it from a slice:

CurrentTheme::PageTemplate

Similarly ViewTemplate and EditTemplate and StyleSheet

CurrentTheme::ViewTemplate CurrentTheme::EditTemplate and CurrentTheme::StyleSheet

This requires a modification to the core code (but it's not too hard). (Note maybe some extra work so that the recursive part of getRecursiveTiddlerText still works, eg getRecursiveTiddlerSlice).

Now we just need a shadow tiddler for CurrentTheme that contains the four slices as per above. (So I suppose we must be able to get slices from shadow tiddlers, a little more work there perhaps).

Now a theme install is simply a single tiddler import. A theme switch is simply a matter of copying any theme tiddler to CurrentTheme.

The bonus is that now we have PartTiddler functionality in the core and accessed via the slice api, nice and easy to explain and document. :)

Note that if recursive text still works then CurrentTheme might initially look like this:

<slice name="ViewTemplate">[[ViewTemplate]]</slice>
<slice name="StyleSheet">[[StyleSheet]]</slice>
<slice name="EditTemplate">[[EditTemplate]]</slice>
<slice name="PageTemplate">[[PageTemplate]]</slice>

This is good because it will work with existing themes right out of the box.

Does it make any sense?

Simon.

[Simon Baird]

I think it could be done with HideWhenPlugin. But perhaps a nice light theme switcher is better.

http://svn.tiddlywiki.org/Trunk/contributors/SimonBaird/mptw/trunk/core/HideWhenPlugin.js

<div macro="showWhenExists TopMenu">
<!-- top menu here -->
</div>

<div macro="showWhenExists MainMenu">
<!-- left menu here -->
</div>

[FND]

> ooo... heresy!

Haha, just what I expected... ;)

>> I wouldn't mind a basic layout switcher in the core and two layouts
>> shipped, one horizontal main menu, one vertical
>

> I've been wondering about the approach of having separate shadow
> tiddlers for both the horizontal and vertical menus (eg, TopMenu vs.
> MainMenu or something).

I'd thought about this as well - but since you'll rarely use both
MainMenu //and// TopMenu, one of those would usually be obsolete - which
carries the risk of bloated core code.
However, this might be a customization/preference worth integrating into
the core...

By the way, I've created a summary of this discussion:
http://tiddlywikiguides.org/index.php?title=TiddlyWiki_redesign
This might make "evaluation" easier later on...

-- F.

[Ken Girard]

Personally I am all for being able to support one or both at the same
time (since I already do both on some of mine). I've even got a couple
with multiple horizontal menus.

Actually I think something that would really be great would be a way
to have main topics in the top menu and then have subtopics show in
the vertical menu when a topic is clicked. But then, that would be a
plugin, not a design feature.

Ken Girard

On May 23, 7:11 am, "Jeremy Ruston" <jeremy.rus...@gmail.com> wrote:
> I've been wondering about the approach of having separate shadow
> tiddlers for both the horizontal and vertical menus (eg, TopMenu vs.
> MainMenu or something). With a bit of care, the layout should be able
> to adapt to either or both of those tiddlers being empty or
> non-existent.
>
> Cheers
>
> Jeremy
>

> On 5/23/07, Simon Baird <simon.ba...@gmail.com> wrote:
>
> > ooo... heresy! I can't see this going ahead (though I wouldn't mind a basic
> > layout switcher in the core and two layouts shipped, one horizontal main
> > menu, one vertical).
>

[lewcid]

On May 23, 2:49 pm, Ken Girard <ken.gir...@gmail.com> wrote:
> Actually I think something that would really be great would be a way
> to have main topics in the top menu and then have subtopics show in
> the vertical menu when a topic is clicked. But then, that would be a
> plugin, not a design feature.

I actually coded something like that for personal use. It's lacking
documentation etc, but if you need it I'd be happy to forward a copy.
Saq

[Jeremy Ruston]

Very nicely put, that's almost exactly what I was proposing.

I'm not a huge fan of faux-XML syntax for the multi-line tiddler
slices. I'd wondered about using something based on the HR syntax:

---- SliceName
Slice content
more content
ending on the next HR or slice marker
----

I also wondered about using headings for marking multiline slices, so
that the content of a slice can be addressed by the text of the
header:

! SliceName
This is the first line
!! SubSlice
This is part of the subslice

Which would raise the question of whether getting the slice
"SliceName" should return both lines, or just the first. Having
sub-addressing tiddler slices may be too ambitious, but the idea of
using headings seems quite TiddlyWiki-ish.

Cheers

Jeremy

[Daniel Baird]

On 23/05/07, FND <Ace_...@gmx.net> wrote:
> >> I wouldn't mind a basic layout switcher in the core and two layouts
> >> shipped, one horizontal main menu, one vertical
> >
> > I've been wondering about the approach of having separate shadow
> > tiddlers for both the horizontal and vertical menus (eg, TopMenu vs.
> > MainMenu or something).
>
> I'd thought about this as well - but since you'll rarely use both
> MainMenu //and// TopMenu, one of those would usually be obsolete - which
> carries the risk of bloated core code.

I think there's be a lot of use for having both left-side and top
menus; I reckon most users would find something to put in each of
them. I'm completely for having both in the core.

Then maybe the code to do the magic hide-when-empty could be a plugin?

;Daniel

[Martin Budden]

I think headings is the way to go. I've also had some further ideas of
how headings could be used. I'll post these when I have more time.

Martin

On 5/23/07, Jeremy Ruston <jeremy...@gmail.com> wrote:
>

[Daniel Baird]

I also love the heading idea. Suddenly every tiddler is a potential
source of structured data..

I'd be inclined to imagine that subheading _content_ should be
included when you refer to tiddler::mainheading, but I can't decide if
the subheading text should itself be considered as "content".

But, I am excited about something like tidder::mainheading::subheading
working. That seems cool.

;Daniel

[Simon Baird]

You would have to "plaintext-ify" the heading name, eg, tell me what the slice name is here:

![[Hey There]] //and so on// ^^[[see also|BlahBlah]]^^

[Martin Budden]

Yes, there's definitely some thinking to be done around the details of
the implementation.

[FND]

> Related is the (new in 2.2) always visible tiddler toolbar buttons.

Speaking of the tiddler toolbar:
Even though I know about the "Jump" menu for navigating open tiddlers, I
actually rarely use it.

It's not that it wasn't useful - it certainly could be - but rather that
it's not ... salient enough.

In fact, maybe this button doesn't belong into the tiddler toolbar at
all, as it's actually more of a "global" command!?

Thoughts? Ideas?

-- F.

[FND]

> maybe this button doesn't belong into the tiddler toolbar at
> all, as it's actually more of a "global" command!?

In fact, the buttons Jump, Close All and PermaView could be moved to a
newly-created toolbar at the top of the #displayArea pane... !?

(There's some danger of confusing the user with too many dispersed
navigation/functionality blocks - but since this would be a logical
alignment, it'd probably do more good than harm.)

-- F.

[Jeremy Ruston]

> In fact, the buttons Jump, Close All and PermaView could be moved to a
> newly-created toolbar at the top of the #displayArea pane... !?

It's kind of a hack, but the reason I put the 'jump' button on the
tiddler toolbar was because it is intended to reduce the amount of
scrolling that a user must do to locate a tiddler that is already
open; if the user had to scroll to the top of the page first to find
the 'jump' button they'd have to do some scrolling before they even
start.

Cheers

Jeremy

[Daniel Baird]

I agree. Saq's got a nice scrolly-menu thingy that stays on screen,
and he moved his jump button there. Makes much more sense.

;D

[FND]

> I put the 'jump' button on the tiddler toolbar was because it is
> intended to reduce the amount of scrolling

Duh, of course - I hadn't thought of that...

Well then, maybe what Daniel just suggested:

> Saq's got a nice scrolly-menu thingy that stays on screen

Not sure how much code (bloat?) that requires though.

-- F.

[David Shaw]

If I can just butt in here - I, personally, loathe this kind of floating
box; I find them intensely irritating. If other people would like this,
then that's fine, but please include a way of switching it off, if you
decide to go down this route.

Personally, I would prefer a fixed title bar which doesn't scroll with
the rest of the page; things such as permalink, jump, references etc.
could go in there somewhere.

But then again, maybe I'm just peculiar ;-)

David Shaw

PS - plenty of people have told me I'm peculiar, so I accept that this
could, indeed, be an option ;-)

[Daniel Baird]

I don't think standard TW should have a floaty-thing (Saq's is quite
minimal though. It might not be as annoying as you'd expect). Just
wanted to point out that the "jump isn't actually related to the
tiddler" issue has been noticed by others.

Having the floaty thing available as a plugin is perfect.

;D

[FND]

> I, personally, loathe this kind of floating box

Come to think of it, those really are quite disturbing sometimes.

I'm afraid Saq's #hoverMenu feels especially irritating - probably
because it's "bouncy" when scrolling: http://tw.lewcid.org/#StyleSheet

> Personally, I would prefer a fixed title bar which doesn't scroll with

> the rest of the page [for] things such as permalink, jump, references

So kinda like "freeze panels" in Excel? I'd like that very much (as it'd
still be pseudo-static, unlike them free-floating boxes)!
However, I can't really imagine a viable solution for this; e.g. how
would you prevent it from overlapping with the header?

btw: I'd seriously disagree about the References button; that one
certainly does belong into the tiddler toolbar...

-- F.

[David Shaw]

>> Personally, I would prefer a fixed title bar which doesn't scroll with
>> the rest of the page [for] things such as permalink, jump, references
>>
>
> So kinda like "freeze panels" in Excel? I'd like that very much (as it'd
> still be pseudo-static, unlike them free-floating boxes)!
> However, I can't really imagine a viable solution for this; e.g. how
> would you prevent it from overlapping with the header?
>

It's half-doable in CSS, but weird things happen due to the need to add
another <div> into the page template. I've tried working out how to get
around this problem, either with plain CSS or hacking the code, but it's
beyond my meagre skills.

> btw: I'd seriously disagree about the References button; that one
> certainly does belong into the tiddler toolbar...
>

Oops! Yes, I wasn't thinking straight there :-)

David

[FND]

> [the fixed title toolbar is] half-doable in CSS

Could you draw up a sample image? I can't really imagine where you'd put
this toolbar...

>> btw: I'd seriously disagree about the References button; that one
>> certainly does belong into the tiddler toolbar...
>
> Oops! Yes, I wasn't thinking straight there :-)

Hehe, no worries...

By the way: How about renaming the "Jump" button to something like
"GoTo" - I guess that'd be less ambiguous (esp. for newbies)!?

Shameless plug:
Since this thread is very much splintered now, it's become real hard to
keep track of all the issues being raised.
Thus I've updated the TWG summary page:
http://tiddlywikiguides.org/index.php?title=TiddlyWiki_redesign

-- F.

[Udo Borkowski]

By the way: How about renaming the "Jump" button to something like
"GoTo" - I guess that'd be less ambiguous (esp. for newbies)!?

You are free to change the "Jump" button to "GoTo" by adding this line to a systemConfig tiddler in your TiddlyWiki:

config.commands.jump.text = "GoTo";



Udo

----------
Udo Borkowski
http://www.abego-software.de

[FND]

> You are free to change the "Jump" button to "GoTo" by adding this line

> to a systemConfig tiddler in your TiddlyWiki [snip]

Thanks, Udo - but I was thinking more of in terms of the general redesign*.
As a fairly experienced TW user, I immediately know what the Jump
command is for. However, less-experienced users might be confused by the
ambiguity. So changing the default label might be a good idea...

By the way: What does everyone think of including a footer (fixed to the
bottom of the screen and/or page) in the default layout? I myself used
to be very enthusiastic about that (check the [tw] archives... ), but
now I'm not so sure anymore.
(Normally I'd create a new branch for this issue, but this thread has
too many of those already.)

-- F.

* Though I guess it's more tweaking the current layout/UI - which is
mighty fine already - rather than a complete overhaul.

[Udo Borkowski]

As a fairly experienced TW user, I immediately know what the Jump
command is for. However, less-experienced users might be confused by the
ambiguity. So changing the default label might be a good idea...

Whether "Jump" or "GoTo" is more intuitive is probably just a matter of taste. "JUMP" is probably just *faster* than "GO to" ;)

Udo

----------
Udo Borkowski
http://www.abego-software.de

[Daniel Baird]

I think it's better to have a single word than a compound WikiWord
kind of thing. More Tufte-approved :)

;Daniel

[Jeremy Ruston]

Indeed, originally I went with "jump" rather than "goto" because it
was a nice iconic single word, and more webby and less technical.
Later on I added "close others" didn't come up a clear one-word
description which rather broke the convention. I'm not sure whether
either "jump" or "goto" is easier to understand than the other.

I do like the idea of a standardised footer very much, and have
experimented with it in the past, but never quite got a decent
cross-browser layout; I'm sure it's possible, though, and I'd be open
to adding it to the standard template.

I'm interested in the position:fixed stuff, the problem has always
been the lack of proper support in IE6. But I've been watching things
like this:

http://www.w3schools.com/browsers/browsers_stats.asp

Seeing the inexorable rise of IE7, I'm wondering if pretty soon we
won't be able to optimise the UI for browsers with position:fixed,
with fallback to the current behaviour in IE6.

Cheers

Jeremy

[FND]

> Later on I added "close others" didn't come up a clear one-word
> description which rather broke the convention.

Nice to know that I'm not the only one pedantic enough to notice such
things... ;)

> I'm not sure whether
> either "jump" or "goto" is easier to understand than the other.

I guess in the end, it's not a big issue either way.
But you might be right; "jump" might indeed be less technical/geeky...

> I do like the idea of a standardised footer very much

Visually, I guess it'd be a nice touch (completing the "frame" around
the #displayArea).
But honestly, I wouldn't know what to put in there - except maybe a
disclaimer or copyright notice and a link to TiddlyWiki.com...

> I'm interested in the position:fixed stuff, the problem has always
> been the lack of proper support in IE6.

ZofBot* tells me there are hacks for that:
http://annevankesteren.nl/2003/08/fixed-positioning
http://www.devnull.tagsoup.com/fixed/
http://www.jessey.net/simon/articles/007.html
I've never actually tried those though.

* http://zofbot.zoffix.com/cgi-bin/db.pl; via irc://irc.freenode.net/css

-- F.

[FND]

By the way, how about styling the sidebar with a border and a background
color, to give it a panel-like look?

On a (somewhat) related note, maybe the #messageArea box should
automatically disappear after a few seconds of showing the "Main
TiddlyWiki file saved" message!?

-- F.

[f7o7]

Sorry, this is kinda late, but I just stumbled on this thread. Have a
look at my fixed title toolbar here:
http://f7o7.tiddlyspot.com/

Unfortunately, I cannot upgrade it to the latest release because of
this:
http://trac.tiddlywiki.org/ticket/349
See also discussion here:
http://groups.google.ca/group/TiddlyWikiDev/browse_thread/thread/bac55de93a41ded6/?hl=en#

There are some other issues with this layout that are beyond my
abilities and I seem to not be able to interest anyone of the "big
guns" here to have a proper look at them. The scrolling does not work
properly (try to "goto" to a tiddler that's already open and is
scrolled out of the window by other tiddlers). I think ideally I would
like the title to be a separate frame (now it is fixed at the top of
the page, with the content scrolling under it), but I could not make
that work at all.

[FND]

> Have a look at my fixed title toolbar

That looks nice!
However, you've made so many modifications to the standard layout, it
might be hard applying that to regular TWs - would you mind giving it a
try? (Though we'd still have to figure out what this kinda toolbar
should look like... )

> I think ideally I wouldlike the title to be a separate frame

Frames are evil, don't use frames if you don't have to.
Plus, since TW is only a single file, I don't think that'd be possible
anyway. (Except if you came up with some URL switches to only display
the respective content - but nobody wants to go there just to make
frames work... )

-- F.

[Daniel Baird]

On 13/06/07, FND <Ace_...@gmx.net> wrote:
>
> I don't think that'd be possible anyway. (Except if you came up with
> some URL switches to only display the respective content - but
> nobody wants to go there just to make frames work... )
>

This is what I call the Programmer's Curse -- the answer to every qis
"Yes, you *could* do that. :)

[Daniel Baird]

On 13/06/07, Daniel Baird <danie...@gmail.com> wrote:
> On 13/06/07, FND <Ace_...@gmx.net> wrote:
> >
> > I don't think that'd be possible anyway. (Except if you came up with
> > some URL switches to only display the respective content - but
> > nobody wants to go there just to make frames work... )
> >
>
> This is what I call the Programmer's Curse -- the answer to every qis
> "Yes, you *could* do that. :)

Stupid Gmail hotkeys.. The answer to every question is "Yes, you
*could* do that."
:)

Sorry for the botched punchline. Welcome to the curse, FND.

[FND]

>> This is what I call the Programmer's Curse -- the answer to every qis
>> "Yes, you *could* do that. :)

Indeed.
As they say, ignorance is bliss...

> Stupid Gmail hotkeys..

Funnily enough, I had perceived that "q" only as a typo at first; it
took your correction mail to make me realize there was a word missing...

But speaking of typos: I'm often horrified when I review my postings on
this list*; there's incoherent sentences, silly typos etc.
For some reason initial proof reading doesn't always work for me. In
forum postings, I usually have to make 3-5 post-publication edits before
I'm satisfied - unfortunately, that's not possible on a mailing list...

Anyways, enough self-disclosure for today, I gotta get back to work.

-- F.

* Yes, I do that - though not for narcissistic reasons, but rather the
opposite... (I guess you might say I have xkcd:
http://forums.xkcd.com/viewtopic.php?t=6382)

[f7o7]

> That looks nice!

Thank you!

> However, you've made so many modifications to the standard layout, it
> might be hard applying that to regular TWs - would you mind giving it a
> try?

see here: http://fixedtitle.tiddlyspot.com/

> Frames are evil, don't use frames if you don't have to.

Ok, thanks for the advice. Now that I've done it to a regular TW, I
think my no-frame approach worked out quite well, with only a few
shortcomings. Now if only someone could have a look at those...

[FND]

> see here: http://fixedtitle.tiddlyspot.com/

Good job bringing this into the "standard format"!
Those issues you mention would have to be resolved before anything like
this could be made official - unfortunately, I have no idea how this
could be done.

As an alternative, maybe something like Walt's DisplayOpenTiddlersPlugin
could be used:
http://oregonstate.edu/~woodswa/tiddlywikiplugs.html#DisplayOpenTiddlersPlugin
This pretty much completely eliminates the need for scrolling - which
might not be desirable default behavior though...

-- F.

[Daniel Baird]

On 14/06/07, f7o7 <ewi...@gmail.com> wrote:

see here: http://fixedtitle.tiddlyspot.com/

Seems completely broken in Opera (9.10 on Windows).. just a huge gradient title bar, the full height of the browser window.

;Daniel