request: list macro should be more cooperative
43 views
Skip to first unread message
PMario
Mar 17, 2011, 11:59:30 AM3/17/11
to TiddlyWiki
Hi folks,
There have been a lot of discussions about templating lately. And it
seems that Jon's <<list>> template stuff made it to the core. Which is
cool.
But it would be cooler, if you could see, which parameters have been
used to create the list.
eg:
<<list filter [tag[asdf]] [sort[customfield]] template:templateName>>
should create:
<ul class='list filter' tag='asdf' sort='customfield'> or may be
<ul class='list filter' tag='asdf' sort='customfield' template='...'>
<<list>> or <<list all>> would produce
<ul class='list all'>
It would make it possible to easily CSS style the created lists. eg:
no {{someBulkyStuff{<<list...>>}}} needed anymore.
It would make it possible to elliminate / simplify some
sidebar .tabContents CSS
====
And imo it would be cool to have drag and drop sorting for those
lists :)
Some time ago I did the StylingPackage [1], which can do this. Using
bookmarklets.
Since the <<list>> macro doesn't tell you, how the list is created, I
needed to create a bulky XList macro [2], just to create some DOM
info, that can be found by the bookmarklets.
I could eliminate the additional plugins needed, if
<<list filter [tag[asdf]] [sort[customfield]]>>
would add some more info into the DOM. Described above.
====
Since the filter functions can be easily expended since 2.6.2
<<list filter [is[public]]>>
should produce
<ul class='list filter' is='public'> ....
====
If the above seems to be to complicated, a jQuery data object could be
added to the <ul> containing the param string.
The class='' should be done anyway.
It would be nice to have it in 2.6.3 :)
have fun!
mario
[1] http://apm-plugins.tiddlyspot.com/#StylingPackage
[2] http://apm-plugins.tiddlyspot.com/#XListPlugin
There have been a lot of discussions about templating lately. And it
seems that Jon's <<list>> template stuff made it to the core. Which is
cool.
But it would be cooler, if you could see, which parameters have been
used to create the list.
eg:
<<list filter [tag[asdf]] [sort[customfield]] template:templateName>>
should create:
<ul class='list filter' tag='asdf' sort='customfield'> or may be
<ul class='list filter' tag='asdf' sort='customfield' template='...'>
<<list>> or <<list all>> would produce
<ul class='list all'>
It would make it possible to easily CSS style the created lists. eg:
no {{someBulkyStuff{<<list...>>}}} needed anymore.
It would make it possible to elliminate / simplify some
sidebar .tabContents CSS
====
And imo it would be cool to have drag and drop sorting for those
lists :)
Some time ago I did the StylingPackage [1], which can do this. Using
bookmarklets.
Since the <<list>> macro doesn't tell you, how the list is created, I
needed to create a bulky XList macro [2], just to create some DOM
info, that can be found by the bookmarklets.
I could eliminate the additional plugins needed, if
<<list filter [tag[asdf]] [sort[customfield]]>>
would add some more info into the DOM. Described above.
====
Since the filter functions can be easily expended since 2.6.2
<<list filter [is[public]]>>
should produce
<ul class='list filter' is='public'> ....
====
If the above seems to be to complicated, a jQuery data object could be
added to the <ul> containing the param string.
The class='' should be done anyway.
It would be nice to have it in 2.6.3 :)
have fun!
mario
[1] http://apm-plugins.tiddlyspot.com/#StylingPackage
[2] http://apm-plugins.tiddlyspot.com/#XListPlugin
Måns
Mar 17, 2011, 1:03:02 PM3/17/11
to TiddlyWiki
Hi Mario
> And it seems that Jon's <<list>> template stuff made it to the core. Which is
> cool.
Has it?
> And imo it would be cool to have drag and drop sorting for those
> lists :)
> Some time ago I did the StylingPackage [1], which can do this. Using bookmarklets.
@jon, what's your opinion?
Cheers Måns Mårtensson
> And it seems that Jon's <<list>> template stuff made it to the core. Which is
> cool.
> And imo it would be cool to have drag and drop sorting for those
> lists :)
> Some time ago I did the StylingPackage [1], which can do this. Using bookmarklets.
> ====
> If the above seems to be to complicated, a jQuery data object could be added to the <ul> containing the param string.
....
> If the above seems to be to complicated, a jQuery data object could be added to the <ul> containing the param string.
> It would be nice to have it in 2.6.3 :)
>====
> [1]http://apm-plugins.tiddlyspot.com/#StylingPackage
> [2]http://apm-plugins.tiddlyspot.com/#XListPlugin
Wauw - I'd love to be able to sort lists like that!!!
> [2]http://apm-plugins.tiddlyspot.com/#XListPlugin
@jon, what's your opinion?
Cheers Måns Mårtensson
PMario
Mar 17, 2011, 1:23:29 PM3/17/11
to TiddlyWiki
On Mar 17, 6:03 pm, Måns <humam...@gmail.com> wrote:
> Hi Mario
>
> > And it seems that Jon's <<list>> template stuff made it to the core. Which is
> > cool.
>
> Has it?
according to the alpha TS core yes
> Hi Mario
>
> > And it seems that Jon's <<list>> template stuff made it to the core. Which is
> > cool.
>
> Has it?
search for config.macros.list.template in [2]
[1] http://pmario.tiddlyspace.com/?twrelease=alpha;external=1
[2] http://pmario.tiddlyspace.com/bags/common/tiddlers/alpha_twcore.js
-m
Eric Shulman
Mar 17, 2011, 2:13:02 PM3/17/11
to TiddlyWiki
> > > And it seems that Jon's <<list>> template stuff made it to the core. Which is
> > > cool.
> > Has it?
>
> according to the alpha TS core yes
TBH, I think the design of this new feature has not been properly
> > > cool.
> > Has it?
>
> according to the alpha TS core yes
considered before being added to the core. It seems like this was
'tossed in' as a quick tweak, without proper *public* discussion or
review of the design or usability issues.
For example, one *minor* issue I have is with the choice of parameter
name. There is already a well-established "template" mechanism within
TiddlyWiki: a template is a tiddler containing HTML syntax used to
produce formatted output. However, Jon's <<list>> macro "templates"
do NOT build on that functionality... instead, Jon's list macro
"template" is really more like using <<tiddler>> transclusion that
merely renders wiki-formatted syntax, but without the ability to
substitute "with:" parameter values into the output.
A more serious issue is the manner in which this addition has
triggered additional core changes in the <<view>> macro. Those core
changes were entirely *reactive*, and were made without much
discussion about appropriate syntax, usability, or even the features
actually desired by the community. If proper discussions had
occurred, then issues like the "case sensitivity problem" for slice
references could have been easily identified and addressed, *before*
the code was checked-in to the core.
From my point-of-view, there appears to be a double standard at work
here. Proposed core changes developed *outside* Osmosoft get a lot of
resistance, languish for months (or *years*), or are repeatedly re-
scheduled for a later release, effectively forcing them to be
implemented as plugins, even if the proposed core change is minimal,
isolated, and well-tested.
In contrast, it seems that changes developed *inside* Osmosoft often
get "fast-tracked" straight into the next release of the core,
resulting in follow-up tickets to fix problems (or add even more
functionality) that could have been identified and addressed
beforehand.
-e
passingby
Mar 17, 2011, 3:14:50 PM3/17/11
to TiddlyWiki
I am a nobody and I feel if a person like Eric says something then
something is going on which nobodies like me do not know of but
somebodies who do know something should probably do something about
this. Let the piece of goodness, which TW is, not be harmed due to any
possible wrong policy.
something is going on which nobodies like me do not know of but
somebodies who do know something should probably do something about
this. Let the piece of goodness, which TW is, not be harmed due to any
possible wrong policy.
Måns
Mar 17, 2011, 5:22:25 PM3/17/11
to TiddlyWiki
@Chris, @Jon, @Paul, @Jeremy, @Colm or @Martin!!!
> A more serious issue is the manner in which this addition has
> triggered additional core changes in the <<view>> macro. Those core
> changes were entirely *reactive*, and were made without much
> discussion about appropriate syntax, usability, or even the features
> actually desired by the community. If proper discussions had
> occurred, then issues like the "case sensitivity problem" for slice
> references could have been easily identified and addressed, *before*
> the code was checked-in to the core.
Hmm..
> From my point-of-view, there appears to be a double standard at work
> here. Proposed core changes developed *outside* Osmosoft get a lot of
> resistance, languish for months (or *years*), or are repeatedly re-
> scheduled for a later release, effectively forcing them to be
> implemented as plugins, even if the proposed core change is minimal,
> isolated, and well-tested.
Hmm ... again.
> In contrast, it seems that changes developed *inside* Osmosoft often
> get "fast-tracked" straight into the next release of the core,
> resulting in follow-up tickets to fix problems (or add even more
> functionality) that could have been identified and addressed
> beforehand.
I believe this particular thread should be in the dev thread.
I sincerely hope someone mentioned in this post will be able to set
things straight...
There was a "refreshing" debate in this post:
https://groups.google.com/group/tiddlywikidev/browse_thread/thread/ec5159b363a7e0d6/0078c69e91ac7aa2
I do not hope that it was in vain, because of this (possible)
mischief?! (it's still at an alfa stage isn't it?)
Chris wrote:
"I think we can agree that increased communication is a good thing.
It
is a main portion of your message, Eric: Activity needs to be
telegraphed more effectively. Couldn't agree more. You are 100%
correct.
It is in the details of how an open source project is to be managed
where there is likey to be disagreement and those are areas in which
I
think _all_ the people on this group can provide excellent input. "
and
"While it may appear like Osmosoft is in the business of
"maintaining TiddlyWiki" this is not true. Osmosoft, at the moment,
does
web development for BT, with TiddlyWiki as one of the primary tools.
I personally would like to see more core commits/patches from Eric.
I think this would a) help move things along, b) increase the
diversity in the code base, and c) be a good example for other people
who want to get their changes in the core. "
and
"What I _did_ suggest was that we can't let backwards compatibility
prevent us from making changes that are important. Yes, when that
happens, we must make sure to communicate how it will impact existing
situations. "
and
"Too many people, inside and out of Osmosoft, think that Osmosoft is
or should be controlling the code.
That's not open source. "
My simple conclusion:
Communication is everything -
Please don't leave Eric's statement uncommented - give him a call, or
a pm..
Cheers Måns Mårtensson
> A more serious issue is the manner in which this addition has
> triggered additional core changes in the <<view>> macro. Those core
> changes were entirely *reactive*, and were made without much
> discussion about appropriate syntax, usability, or even the features
> actually desired by the community. If proper discussions had
> occurred, then issues like the "case sensitivity problem" for slice
> references could have been easily identified and addressed, *before*
> the code was checked-in to the core.
> From my point-of-view, there appears to be a double standard at work
> here. Proposed core changes developed *outside* Osmosoft get a lot of
> resistance, languish for months (or *years*), or are repeatedly re-
> scheduled for a later release, effectively forcing them to be
> implemented as plugins, even if the proposed core change is minimal,
> isolated, and well-tested.
> In contrast, it seems that changes developed *inside* Osmosoft often
> get "fast-tracked" straight into the next release of the core,
> resulting in follow-up tickets to fix problems (or add even more
> functionality) that could have been identified and addressed
> beforehand.
I sincerely hope someone mentioned in this post will be able to set
things straight...
There was a "refreshing" debate in this post:
https://groups.google.com/group/tiddlywikidev/browse_thread/thread/ec5159b363a7e0d6/0078c69e91ac7aa2
I do not hope that it was in vain, because of this (possible)
mischief?! (it's still at an alfa stage isn't it?)
Chris wrote:
"I think we can agree that increased communication is a good thing.
It
is a main portion of your message, Eric: Activity needs to be
telegraphed more effectively. Couldn't agree more. You are 100%
correct.
It is in the details of how an open source project is to be managed
where there is likey to be disagreement and those are areas in which
I
think _all_ the people on this group can provide excellent input. "
and
"While it may appear like Osmosoft is in the business of
"maintaining TiddlyWiki" this is not true. Osmosoft, at the moment,
does
web development for BT, with TiddlyWiki as one of the primary tools.
I personally would like to see more core commits/patches from Eric.
I think this would a) help move things along, b) increase the
diversity in the code base, and c) be a good example for other people
who want to get their changes in the core. "
and
"What I _did_ suggest was that we can't let backwards compatibility
prevent us from making changes that are important. Yes, when that
happens, we must make sure to communicate how it will impact existing
situations. "
and
"Too many people, inside and out of Osmosoft, think that Osmosoft is
or should be controlling the code.
That's not open source. "
My simple conclusion:
Communication is everything -
Please don't leave Eric's statement uncommented - give him a call, or
a pm..
Cheers Måns Mårtensson
Eric Shulman
Mar 17, 2011, 5:38:13 PM3/17/11
to TiddlyWiki
> possible wrong policy.
I do not think that there is a "policy", formal or otherwise, at work
here. Rather, I think that whatever process-related issues exist,
they are unintended, and simply an effect of normal group dynamics
that result in more support for "insider" priorities, as compared to
"outsider" priorities -- a.k.a., the well-known "NIH" ("Not Invented
Here") effect.
In any case, my only intention is to shine a light on the TWCore
development process in order to improve the end result. There is no
question in my mind that *everyone* shares the same general goal: to
continually improve the functionality, performance, and overall
usability of TiddlyWiki.
Nonetheless, from a social standpoint alone, the impression -- whether
accurate or not -- that there IS an "insider-vs-outsider" schism with
regard to TWCore development should be of some concern, and is a good
topic for discussion for the entire TiddlyWiki community.
Here's a few questions to get the conversation rolling:
* How should new TWCore features proposed and refined? e.g., online
discussions, tickets, conference calls, emails, personal
conversations, formal RFPs/RFCs (YUCK!), etc.
* What criteria are used to evaluate new features? e.g., public
demand, code complexity/risk, adaptability (plugin potential),
backward-compatibility, cross-platform compatibility, etc.
* How are release dates/priorities set?
your thoughts?
-e
I do not think that there is a "policy", formal or otherwise, at work
here. Rather, I think that whatever process-related issues exist,
they are unintended, and simply an effect of normal group dynamics
that result in more support for "insider" priorities, as compared to
"outsider" priorities -- a.k.a., the well-known "NIH" ("Not Invented
Here") effect.
In any case, my only intention is to shine a light on the TWCore
development process in order to improve the end result. There is no
question in my mind that *everyone* shares the same general goal: to
continually improve the functionality, performance, and overall
usability of TiddlyWiki.
Nonetheless, from a social standpoint alone, the impression -- whether
accurate or not -- that there IS an "insider-vs-outsider" schism with
regard to TWCore development should be of some concern, and is a good
topic for discussion for the entire TiddlyWiki community.
Here's a few questions to get the conversation rolling:
* How should new TWCore features proposed and refined? e.g., online
discussions, tickets, conference calls, emails, personal
conversations, formal RFPs/RFCs (YUCK!), etc.
* What criteria are used to evaluate new features? e.g., public
demand, code complexity/risk, adaptability (plugin potential),
backward-compatibility, cross-platform compatibility, etc.
* How are release dates/priorities set?
your thoughts?
-e
Jeremy Ruston
Mar 17, 2011, 5:51:17 PM3/17/11
to tiddl...@googlegroups.com, Måns
I'm very conscious that TiddlyWiki core development got rather
moribund over the years. We've discussed some of the reasons and the
symptoms before. As you've seen from the discussion quoted by Måns,
Osmosoft has undertaken to shake things up and improve our speed and
transparency. Eric is entirely correct that these new changes popping
up in the alpha without discussion is not exactly best practice. It's
a work in progress as we try to improve how we work together, devising
better processes that are more transparent, and everyone's feedback is
very valuable as we figure things out.
moribund over the years. We've discussed some of the reasons and the
symptoms before. As you've seen from the discussion quoted by Måns,
Osmosoft has undertaken to shake things up and improve our speed and
transparency. Eric is entirely correct that these new changes popping
up in the alpha without discussion is not exactly best practice. It's
a work in progress as we try to improve how we work together, devising
better processes that are more transparent, and everyone's feedback is
very valuable as we figure things out.
Best wishes
Jeremy
> --
> You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
> To post to this group, send email to tiddl...@googlegroups.com.
> To unsubscribe from this group, send email to tiddlywiki+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/tiddlywiki?hl=en.
>
>
--
Jeremy Ruston
mailto:jer...@osmosoft.com
http://www.tiddlywiki.com
Måns
Mar 17, 2011, 8:34:31 PM3/17/11
to TiddlyWiki
> ... there IS an "insider-vs-outsider" schism with
> * How should new TWCore features proposed and refined? e.g., online
> discussions, tickets, conference calls, emails, personal
> conversations, formal RFPs/RFCs (YUCK!), etc.
As en enduser I would like to be able to follow development
anticipating a release on the devgroup.
I would "pay my 2 cents" there, whenever I thought I could add
something usefull myself.
I would expect to get more than just an announcement of a new
release..
> * What criteria are used to evaluate new features? e.g., public
> demand, code complexity/risk, adaptability (plugin potential),
> backward-compatibility, cross-platform compatibility, etc.
I'd like to be able to vote for "public demand", however I would be
*very* responsive, whenever a develloper/programmer explained the
adaptability of a possible new feature, and my vote would reflect just
how responsive I am as a potential user of TiddlyWiki for many years
to come (I hope..)..
I'm not very concerned about backwards compability, unless we are
talking about wikitext, evaluated parameters and
forEachTiddlerPlugin... Then I *am* pretty concerned...
If I get WysiWyg as a full replacement for wikitext - no evaluable
parameters via the tiddlermacro and no help from fET, then it's
comparable to taking a kids Lego bricks and replace it with readymade
toys - no more fun or creativity left for someone like me :-(
I still have a bunch of "old" TWs which won't work if they are
upgraded, however they work as they are now - so why upgrade? One
example is the jTab plugin http://jtab.tardate.com/jtabtwiki-help.htm,
I haven't been able to make it work since TW ver. 2.5.3... However I
use it still, I just don't upgrade the core...
If I'm told that I can get more and better "legobricks", but I have to
forget about some plugins, that the plugindevelopper doesn't want to
maintain or adjust to meet the new demands, then I can choose to
upgrade "with my eyes open" - and I would happily write a section
about "known issues" to inform/warn other users about the
consequences...
TiddlyWiki isn't just *one* program, it becomes a new application
everytime you have tailored it for a new usercase. If it works for
that particular usercase, that's fine, and it doesn't need to be
upgraded unless the conditions for the usercase changes. If they do
and need some refactoring a new plugin which depends on something
still unsupported by the core, what are my chances to make things work
with TiddlyWiki? I don't know? - Mayby some other software maintained
by someone who gets paid to deliver superficial solutions/results as
fast as possible... - Problem is that you can only afford to pay a few
- TiddlyWiki on the other hand has *many* eager contributors (both
amateurs, semiprofessionals and pros) of plugins and code - Most of
them give their work away for free, however there's a certain
expectation of high quality and sensation - and I believe that it must
be worth it somehow - maybe its enough to experience that other users
respect and use their work - don't know. To mee it seems that quality
is a keyword here?! - and I think this goes for everybody involved in
the TiddlyWiki project..
My 2 cents...
Cheers Måns Mårtensson
> regard to TWCore development should be of some concern, and is a good
> topic for discussion for the entire TiddlyWiki community.
Ok..
> topic for discussion for the entire TiddlyWiki community.
> * How should new TWCore features proposed and refined? e.g., online
> discussions, tickets, conference calls, emails, personal
> conversations, formal RFPs/RFCs (YUCK!), etc.
anticipating a release on the devgroup.
I would "pay my 2 cents" there, whenever I thought I could add
something usefull myself.
I would expect to get more than just an announcement of a new
release..
> * What criteria are used to evaluate new features? e.g., public
> demand, code complexity/risk, adaptability (plugin potential),
> backward-compatibility, cross-platform compatibility, etc.
*very* responsive, whenever a develloper/programmer explained the
adaptability of a possible new feature, and my vote would reflect just
how responsive I am as a potential user of TiddlyWiki for many years
to come (I hope..)..
I'm not very concerned about backwards compability, unless we are
talking about wikitext, evaluated parameters and
forEachTiddlerPlugin... Then I *am* pretty concerned...
If I get WysiWyg as a full replacement for wikitext - no evaluable
parameters via the tiddlermacro and no help from fET, then it's
comparable to taking a kids Lego bricks and replace it with readymade
toys - no more fun or creativity left for someone like me :-(
I still have a bunch of "old" TWs which won't work if they are
upgraded, however they work as they are now - so why upgrade? One
example is the jTab plugin http://jtab.tardate.com/jtabtwiki-help.htm,
I haven't been able to make it work since TW ver. 2.5.3... However I
use it still, I just don't upgrade the core...
If I'm told that I can get more and better "legobricks", but I have to
forget about some plugins, that the plugindevelopper doesn't want to
maintain or adjust to meet the new demands, then I can choose to
upgrade "with my eyes open" - and I would happily write a section
about "known issues" to inform/warn other users about the
consequences...
TiddlyWiki isn't just *one* program, it becomes a new application
everytime you have tailored it for a new usercase. If it works for
that particular usercase, that's fine, and it doesn't need to be
upgraded unless the conditions for the usercase changes. If they do
and need some refactoring a new plugin which depends on something
still unsupported by the core, what are my chances to make things work
with TiddlyWiki? I don't know? - Mayby some other software maintained
by someone who gets paid to deliver superficial solutions/results as
fast as possible... - Problem is that you can only afford to pay a few
- TiddlyWiki on the other hand has *many* eager contributors (both
amateurs, semiprofessionals and pros) of plugins and code - Most of
them give their work away for free, however there's a certain
expectation of high quality and sensation - and I believe that it must
be worth it somehow - maybe its enough to experience that other users
respect and use their work - don't know. To mee it seems that quality
is a keyword here?! - and I think this goes for everybody involved in
the TiddlyWiki project..
My 2 cents...
Cheers Måns Mårtensson
FrD
Mar 18, 2011, 3:11:05 AM3/18/11
to TiddlyWiki
I'm not a big contributor to the groups (TW and TWdev) but I feel
strongly concerned
with TW. I like this tool and I use it for personal and semi-
professional purposes.
I was pleased to see there was a new impulse in the TWDev group.
But I was disappointed when I read this thread.
As Eric I'd like to see a more balanced approach to core development.
And simply put I'd like to have some informations on the new features
that are
proposed for the new versions.
>
> * How should new TWCore features proposed and refined? e.g., online
> discussions, tickets, conference calls, emails, personal
> conversations, formal RFPs/RFCs (YUCK!), etc.
I'd prefer some informal discussions on main topics, or important
changes,
here or better on TWDev
>
> * What criteria are used to evaluate new features? e.g., public
> demand, code complexity/risk, adaptability (plugin potential),
> backward-compatibility, cross-platform compatibility, etc.
I'm not very concerned with backward compatibility, since I use only
some plugins mainly from tiddlytools and I'm pretty sure Eric will
adapt his work to the new features (?!)
I think public demand through this forum is a good criterium.
>
And I agree with everything Måns said about "legobricks" :-)
FrD
strongly concerned
with TW. I like this tool and I use it for personal and semi-
professional purposes.
I was pleased to see there was a new impulse in the TWDev group.
But I was disappointed when I read this thread.
As Eric I'd like to see a more balanced approach to core development.
And simply put I'd like to have some informations on the new features
that are
proposed for the new versions.
>
> * How should new TWCore features proposed and refined? e.g., online
> discussions, tickets, conference calls, emails, personal
> conversations, formal RFPs/RFCs (YUCK!), etc.
changes,
here or better on TWDev
>
> * What criteria are used to evaluate new features? e.g., public
> demand, code complexity/risk, adaptability (plugin potential),
> backward-compatibility, cross-platform compatibility, etc.
some plugins mainly from tiddlytools and I'm pretty sure Eric will
adapt his work to the new features (?!)
I think public demand through this forum is a good criterium.
>
And I agree with everything Måns said about "legobricks" :-)
FrD
rakugo
Mar 18, 2011, 4:24:50 AM3/18/11
to TiddlyWiki
If there are some issues with the implementation a thread should of
course be started straight away in TiddlyWikiDev to resolve these. It
is only an alpha version after all.
In terms of how TiddlyWiki development works, as far as I'm concerned
I raised a ticket for this *3 months* ago on trac:
http://trac.tiddlywiki.org/ticket/1286
There was absolutely no discussion on the ticket or issues raised or
even a thread on the group disputing it and 3 months seems plenty of
time to. I constantly monitor trac tickets and chip in where necessary
(albeit this happens very rarely). Also it points out that since there
are lot of tickets that go untouched for months/years without any
discussion/development these are just noise that distract from other
more important issues... as a result maybe this was why this ticket
was not noticed.
I also maintained backwards compatibility by breaking no tests with my
proposed changes and even adding tests to the core to make sure it
would continue to be stable.
This sounds like a process issue that we need to iron out.
Personally I would like to see more tests in TiddlyWiki and more
activity on TiddlyWiki tickets driving development - the ticket should
be the single thing that drives development in this project.
Jon
course be started straight away in TiddlyWikiDev to resolve these. It
is only an alpha version after all.
In terms of how TiddlyWiki development works, as far as I'm concerned
I raised a ticket for this *3 months* ago on trac:
http://trac.tiddlywiki.org/ticket/1286
There was absolutely no discussion on the ticket or issues raised or
even a thread on the group disputing it and 3 months seems plenty of
time to. I constantly monitor trac tickets and chip in where necessary
(albeit this happens very rarely). Also it points out that since there
are lot of tickets that go untouched for months/years without any
discussion/development these are just noise that distract from other
more important issues... as a result maybe this was why this ticket
was not noticed.
I also maintained backwards compatibility by breaking no tests with my
proposed changes and even adding tests to the core to make sure it
would continue to be stable.
This sounds like a process issue that we need to iron out.
Personally I would like to see more tests in TiddlyWiki and more
activity on TiddlyWiki tickets driving development - the ticket should
be the single thing that drives development in this project.
Jon
Ben Gillies
Mar 18, 2011, 4:42:43 AM3/18/11
to tiddl...@googlegroups.com
> I believe this particular thread should be in the dev thread.
Indeed. I'll keep this brief then, and just outline my (personal) opinions.
> I personally would like to see more core commits/patches from Eric.
Quite. This would be awesome. Hopefully the move to git (and I suppose github) will make this a lot easier.
> I think this would a) help move things along, b) increase the
> diversity in the code base, and c) be a good example for other people
> who want to get their changes in the core. "
Again, I quite agree. As the development speed of TiddlyWiki increases, it becomes more important to get outside involvement. As Jon implies, trac isn't doing that very well. Hopefully (as evidenced by other projects (including TiddlySpace)) github should make that a lot easier.
Until that happens though, we're likely to see mismatches between the speed we want to go, and the speed that the current setup allows us to go.
>
> and
>
> "What I _did_ suggest was that we can't let backwards compatibility
> prevent us from making changes that are important. Yes, when that
> happens, we must make sure to communicate how it will impact existing
> situations. "
Indeed. I think TiddlyWikiDev is a good place for that.
>
> and
>
> "Too many people, inside and out of Osmosoft, think that Osmosoft is
> or should be controlling the code.
> That's not open source. "
I'd love more outside involvement with the codebase. And again, that's one of the reasons we're moving things to github.
Ben
Ben Gillies
Mar 18, 2011, 5:18:45 AM3/18/11
to tiddl...@googlegroups.com
> And I agree with everything Måns said about "legobricks" :-)
Yep. Agree here too. Lego bricks are very important, and one of the things that make TiddlyWiki really cool and such a joy to use.
I'd like to give my (personal) take on this though, in an attempt to explain what's happening (and hopefully to allay your fears). (again, this is my personal take)
The majority of coding is currently done (within Osmosoft) with TiddlySpace in mind (and extensions to TiddlyWiki are applied when it seems appropriate to do so), and in doing so, that brings with it a whole new set of concerns that are simply not present in classic offline TiddlyWiki. The templating in the list macro for example, is not an attempt to remove Lego bricks, rather, it is an attempt to add in some new Lego bricks that you can play around with, reuse, etc. The difference with these Lego bricks (as compared to fEt) though, is that these new ones are hopefully easier to share securely within TiddlySpace. That's not to say that fEt is a bad thing, rather that its more suited to classic TiddlyWiki, where you're relatively free of attackers.
Similarly, the choice of wikitext over the standard HTML templating reflects the fact that HTML is somewhat harder to sanitize than wikitext (whilst wikitext still allows for a large amount of expressivity). That's not to say its the right choice, rather that that's one of the factors involved in making such a decision.
My (personal) hope is that the list templating will uncover some new and really interestingly shaped Lego bricks that we haven't thought of yet, and thus expand rather than shrink the amount available.
As to the point about wysiwyg, I can think of nothing more horrible. So I wouldn't worry too much about that.
One final point about communication (that I've just thought of, I've personally been expressing my thoughts on this sort of thing within TiddlySpace itself, as they don't tend to get as cluttered as I imagine this post is. For the most part, I've been doing this through experimentation with new spaces (all of which are listed in my home space), and through creating tiddlers in my home space directly (I tag the interesting ones with "blog"). If you're interested, my space is at http://bengillies.tiddlyspace.com (if you don't already know).
Thanks
Ben
tiddlygrp
Mar 18, 2011, 5:50:58 AM3/18/11
to TiddlyWiki
Hi,
On Mar 18, 10:18 am, Ben Gillies <bengill...@gmail.com> wrote:
[snip]
seems that osmosoft is moving towards tiddlyweb/space. So how will
tiddlywiki go further?
The adaptions osmosoft proposes are often/sometimes tiddlyweb
specific. I would really more appreciate a *documented* server
interface. E.g. that would allow a user/developer to (more) easily
just replace server requirements with local storage. It would also
help to clarify: what is tiddlywiki, what is tiddlyweb in terms of
code. Maybe a practical approach could be to add some js to tiddlers
requiring a server backend like:
requireServer which would alert the user on this.
But really I think tiddlywiki is not tiddlyweb. In my view tiddlyweb
is more like a CMS thing like drupal or something like couchdb.
For me it would be important to know the vision of osmosoft with
respect to tiddlywiki. If tiddlywiki is "just" going to be a frontend
to tiddlyweb I think a lot of attractiveness is going away.
thanks,
Vlak
On Mar 18, 10:18 am, Ben Gillies <bengill...@gmail.com> wrote:
[snip]
> The majority of coding is currently done (within Osmosoft) with TiddlySpace
> in mind (and extensions to TiddlyWiki are applied when it seems appropriate
> to do so), and in doing so, that brings with it a whole new set of concerns
> that are simply not present in classic offline TiddlyWiki.
This is what really concerns me about the future of tiddlywiki. It
> in mind (and extensions to TiddlyWiki are applied when it seems appropriate
> to do so), and in doing so, that brings with it a whole new set of concerns
> that are simply not present in classic offline TiddlyWiki.
seems that osmosoft is moving towards tiddlyweb/space. So how will
tiddlywiki go further?
The adaptions osmosoft proposes are often/sometimes tiddlyweb
specific. I would really more appreciate a *documented* server
interface. E.g. that would allow a user/developer to (more) easily
just replace server requirements with local storage. It would also
help to clarify: what is tiddlywiki, what is tiddlyweb in terms of
code. Maybe a practical approach could be to add some js to tiddlers
requiring a server backend like:
requireServer which would alert the user on this.
But really I think tiddlywiki is not tiddlyweb. In my view tiddlyweb
is more like a CMS thing like drupal or something like couchdb.
For me it would be important to know the vision of osmosoft with
respect to tiddlywiki. If tiddlywiki is "just" going to be a frontend
to tiddlyweb I think a lot of attractiveness is going away.
thanks,
Vlak
chris...@gmail.com
Mar 18, 2011, 5:58:14 AM3/18/11
to TiddlyWiki
On Mar 17, 9:22 pm, Måns <humam...@gmail.com> wrote:
> @Chris, @Jon, @Paul, @Jeremy, @Colm or @Martin!!!
Since I'm called out by name here in this message I'll respond here,
> @Chris, @Jon, @Paul, @Jeremy, @Colm or @Martin!!!
but I'm mostly responding to the thread as a whole. I think there are
competing forces and concerns at work in this thread, so the picture
is simultaneously quite simple and not that big of a deal while also
an important part of the evolution and discovery of new processes.
Some thoughts, including a bit of a review of some things that I think
we already decided about process:
* code should be the engine of change in an open source project
This means that making commits is the most forthright and inclusive
way of bringing about change and discussion in the "product". Rather
than waiting until there is consensus before experimenting it is more
productive to experiment to generate discussion and build consensus on
the back of real code rather than speculation. This means that for
alpha level changes (which this is) it is the responsibility of
interested parties to stay abreast of changes via commit messages and
tracking tickets. It is hoped that the migration to github (starting
today of all goes well) will help make those changes more accessible.
* this particular change is only in an alpha, thus far
This means that it can still change. Note that a large reason people
are even aware of it is because alpha capabilities have been exposed
on TiddlySpace. Understand how powerful this is: You can try your
existing Tiddly-content against an alpha core at no cost just by
changing the URI. This means we can theoretically get up to 1000
people testing an alpha before it even becomes a beta. That means the
number of eyes on the functionality is high and we have greater change
of getting it right before it becomes released.
* there was consensus that development was stalled/moribund and
insufficiently reactive to modern times
To combat that one of the things to do is to react to contemporary
requirements. To complain that one change is happening before another,
or one change is cascading other changes in the system seems a bit
specious. We should be celebrating that there is change at all. An
alive open source project is about change and about reacting to needs
across the full diversity of the community.
* commits and tools matter
This particular change made it in quickly because somebody made a
commit. There are quite a few tickets out there that have suggested
changes on them, but it is the nature of the beast that committed code
is far more likely to be released than code that somebody needs to
integrate. Eric has many worthwhile changes that are pending, but if
my information is correct (and I confess it may not be, as there's
lots of hearsay, so please correct me if I'm wrong), Eric has not been
willing to use subversion, despite being invited to do so. When we
move to github the primary way to drive the code will be via forks and
pull requests. That is: If you want something in the core, and you
know how to do it, then write it up in a fork and submit a pull
request. If you don't know how to do these things then learn, the web
is full of instruction.
Related to this, I suspect, are some of the concerns about NIH. It
probably does seem like some of the work done to improve the core or
to create plugins duplicate effort already done somewhere in
TiddlyTools. This is unfortunate and we should work to remedy it.
However, while tiddlytools is an incredible resource for gaining
useful plugins to do cool stuff, as a developer's resource it is not
great: As far as I know, the plugins are not in version control not
accessible individually over http from svn or git and don't use cook
recipe files to build standalones. For developers who do use those
(fairly standard on the web) tools, that's a hinderance.
(It should be noted somewhere in this that I do not develop TiddlyWiki
plugins myself and only very recently got involved in helping to
coordinate TiddlyWiki core development. My interest is on the
serverside. This means that much of my information is biased by
hearsay and superficial observations. My apologies for errors, please
correct me.)
* going where the action is
It is true that TiddlySpace is going to drive a lot of the changes
that happen in TiddlyWiki over the next few months. This is simply a
matter of numbers. There are lots of people using TiddlySpace and they
are stretching TiddlyWiki in weird and wonderful ways. This will make
TiddlyWiki better for all users, not just TiddlySpace users.
* changing attitudes towards releases
One of the goals with making alphas and betas more visible is to
drastically accelerate the release cycle of TiddlyWiki, to get rid of
the sense of morbidity and staleness. That this discussion has come up
at all is a good sign. It means that a) people have noticed some
changes, b) feel empowered to comment on them. Making alphas available
more often will help this happen more often.
[eric]
> > From my point-of-view, there appears to be a double standard at work
> > here. Proposed core changes developed *outside* Osmosoft get a lot of
> > resistance, languish for months (or *years*), or are repeatedly re-
> > scheduled for a later release, effectively forcing them to be
> > implemented as plugins, even if the proposed core change is minimal,
> > isolated, and well-tested.
When we get on github, get an account, join the game.
> > here. Proposed core changes developed *outside* Osmosoft get a lot of
> > resistance, languish for months (or *years*), or are repeatedly re-
> > scheduled for a later release, effectively forcing them to be
> > implemented as plugins, even if the proposed core change is minimal,
> > isolated, and well-tested.
> > In contrast, it seems that changes developed *inside* Osmosoft often
> > get "fast-tracked" straight into the next release of the core,
> > resulting in follow-up tickets to fix problems (or add even more
> > functionality) that could have been identified and addressed
> > beforehand.
feature, see that it is not quite right, tweak it, release again.
Release early and often is the mantra of the open source world. It is
a mantra that TiddlyWiki has forgotten and needs to get back.
If we release alpha's early and often and make them visible, then
people who need stability can avoid them, while people who are doing
development, like being on the bleeding edge or need new features
_now_ have an option. In the past they did not have that option.
Elsewhere in the thread Jeremy says:
"Eric is entirely correct that these new changes popping up in the
alpha without discussion is not exactly best practice. It's a work in
progress as we try to improve how we work together, devising better
processes that are more transparent, and everyone's feedback is very
valuable as we figure things out."
to bring about discussion. Ideally interested parties will read
tickets and commit messages, but barring that available code is the
best way for people to really evaluate a feature. When we get onto
github people will be able to point the mailing list to their forks
and says things like "try this empty.html I built with support for
backbone.js", but right now one of the easiest ways to get feedback is
to get the alpha out there.
Feedback is what makes things happen, and feedback which is based on
real code and real product rather than speculative discussion is far
more useful.
So to sum:
* Nothing too bad going on here, it is the process working. Join in
the conversation if you have concerns.
* Participating in the generation of code means using and attending to
the tools associated with the code. Starting very soon that will mean
github, git, and the github issues system.
PMario
Mar 18, 2011, 6:05:43 AM3/18/11
to TiddlyWiki
@FrD & @passingby
I didn't want to worry anyone.
I _didn't_ post this topic to TW group by accident.
I just wanted to have more different opinions.
For the CSS formating stuff and the possibility to improve my plugins,
mentioned in my first post.
I was really happy, to test the upcomming features with TiddlySpace.
And since the version is not released yet, I thought it would be good
to point out, that I'd want some "legobricks" too and how they should
look like :)
There is more to say.
I'll directly post to other topics. But I'll need some time.
-m
I didn't want to worry anyone.
I _didn't_ post this topic to TW group by accident.
I just wanted to have more different opinions.
For the CSS formating stuff and the possibility to improve my plugins,
mentioned in my first post.
I was really happy, to test the upcomming features with TiddlySpace.
And since the version is not released yet, I thought it would be good
to point out, that I'd want some "legobricks" too and how they should
look like :)
There is more to say.
I'll directly post to other topics. But I'll need some time.
-m
rakugo
Mar 18, 2011, 6:10:54 AM3/18/11
to TiddlyWiki
Oh and in answer to your original question, it seems that the list
macro could benefit from a refresh mechanism. This would mean the
entire parameter string would be accessible via a params attribute and
would also update when tiddlers change (you could thus do
paramString.parseParams).
To demonstrate the lack of a refresh mechanism create a tiddler "1"
with text:
<<list filter [tag[foo]]>>
Now create another tiddler "2" tagged foo and save. The list in "1"
will not show "2" until you reload it/edit and cancel. A refresh
mechanism would make this automatically update.
I must also add that I agree with everything Chris is saying. It's
great that these changes are more visible and getting the attention
they deserve before becoming core. It makes the project much more
exciting to develop in.
macro could benefit from a refresh mechanism. This would mean the
entire parameter string would be accessible via a params attribute and
would also update when tiddlers change (you could thus do
paramString.parseParams).
To demonstrate the lack of a refresh mechanism create a tiddler "1"
with text:
<<list filter [tag[foo]]>>
Now create another tiddler "2" tagged foo and save. The list in "1"
will not show "2" until you reload it/edit and cancel. A refresh
mechanism would make this automatically update.
I must also add that I agree with everything Chris is saying. It's
great that these changes are more visible and getting the attention
they deserve before becoming core. It makes the project much more
exciting to develop in.
PMario
Mar 18, 2011, 6:42:19 AM3/18/11
to TiddlyWiki
On Mar 17, 7:13 pm, Eric Shulman <elsdes...@gmail.com> wrote:
> > > > And it seems that Jon's <<list>> template stuff made it to the core. Which is
> > > > cool.
> > > Has it?
>
> > according to the alpha TS core yes
>
> TBH, ...
> > > > And it seems that Jon's <<list>> template stuff made it to the core. Which is
> > > > cool.
> > > Has it?
>
> > according to the alpha TS core yes
>
TBH? and from other post.
RFPs/RFCs (YUCK!). I don't know these TLAs [1]
> ... I think the design of this new feature has not been properly
> considered before being added to the core. It seems like this was
> 'tossed in' as a quick tweak, without proper *public* discussion or
> review of the design or usability issues.
>
> For example, one *minor* issue I have is with the choice of parameter
> name. ...
> 'tossed in' as a quick tweak, without proper *public* discussion or
> review of the design or usability issues.
>
> For example, one *minor* issue I have is with the choice of parameter
There may be a naming conflict. But in my opinion, the <<list>>
template mechanism has nothing to do with the TW theme mechanism. Nor
with Edit- or ViewTemplate and there derivatives.
> ... There is already a well-established "template" mechanism within
> TiddlyWiki: a template is a tiddler containing HTML syntax used to
> produce formatted output. However, Jon's <<list>> macro "templates"
> do NOT build on that functionality... instead, Jon's list macro
> "template" is really more like using <<tiddler>> transclusion that
> merely renders wiki-formatted syntax, but without the ability to
> substitute "with:" parameter values into the output.
Right. Are there any existing plugins, that use "template:" as a named
> produce formatted output. However, Jon's <<list>> macro "templates"
> do NOT build on that functionality... instead, Jon's list macro
> "template" is really more like using <<tiddler>> transclusion that
> merely renders wiki-formatted syntax, but without the ability to
> substitute "with:" parameter values into the output.
parameter and are used in a totally different context?
The discussion about parameters and there names may be done at TWdev
group.
> A more serious issue is the manner in which this addition has
> triggered additional core changes in the <<view>> macro. Those core
> changes were entirely *reactive*, and were made without much
> discussion about appropriate syntax, usability, or even the features
> actually desired by the community. If proper discussions had
> occurred, then issues like the "case sensitivity problem" for slice
> references could have been easily identified and addressed, *before*
> the code was checked-in to the core.
reachable with special parameters only. As 2.6.2 came out I personally
didn't test it prior to it's official release, because I don't want to
permanently include a beta core into my "working" TWs. So I had to
wait until it's release and found out, that the SystemSettings feature
needed some fixing. I deffinitely like the new mechanism, where I have
the possibility to test prior to the release, with a "working" TW
involved. But easily switching back.
> From my point-of-view, there appears to be a double standard at work
> here. Proposed core changes developed *outside* Osmosoft get a lot of
> resistance, languish for months (or *years*), or are repeatedly re-
> scheduled for a later release, effectively forcing them to be
> implemented as plugins, even if the proposed core change is minimal,
> isolated, and well-tested.
> In contrast, it seems that changes developed *inside* Osmosoft often
> get "fast-tracked" straight into the next release of the core,
> resulting in follow-up tickets to fix problems (or add even more
> functionality) that could have been identified and addressed
> beforehand.
>
> -e
I didn't intend a general discussion about the core. But it seems to
be necessary.
-m
[1] Three Letter Acronyms
PMario
Mar 18, 2011, 7:21:43 AM3/18/11
to TiddlyWiki
On Mar 18, 9:24 am, rakugo <jdlrob...@gmail.com> wrote:
> If there are some issues with the implementation a thread should of
> course be started straight away in TiddlyWikiDev to resolve these. It
> is only an alpha version after all.
+1
> If there are some issues with the implementation a thread should of
> course be started straight away in TiddlyWikiDev to resolve these. It
> is only an alpha version after all.
> In terms of how TiddlyWiki development works, as far as I'm concerned
> I raised a ticket for this *3 months* ago on trac:http://trac.tiddlywiki.org/ticket/1286
use it's interface. And there are allready enough places to listen to.
I followed Mans thread about "templating".
> This sounds like a process issue that we need to iron out.
>
> Personally I would like to see more tests in TiddlyWiki and more
> activity on TiddlyWiki tickets driving development - the ticket should
> be the single thing that drives development in this project.
> Jon
github, is not that effective than posting something to TW-dev group,
or TiddlyWeb, TiddlyWiki group.
First off all, for me, the psychological barrier, posting to a ticket
system, is much much higher, than posting to a user group. And since
there is no official statement, that the ticket system is the _only_
way, to get things done, I'll use the easy way first.
Second. I simply couldn't figure out, how to write valid tickets, yet.
Valid for me means, that something happens, similar to a way I ment
it. In my feelings, some tickets where closed, due to impropper
formulation. Which for sure was true but this won't/can't happen in a
discussion group.
-m
PMario
Mar 22, 2011, 5:04:45 AM3/22/11
to TiddlyWiki
On Mar 18, 11:10 am, rakugo <jdlrob...@gmail.com> wrote:
> Oh and in answer to your original question, it seems that the list
> macro could benefit from a refresh mechanism. This would mean the
> entire parameter string would be accessible via a params attribute and
> would also update when tiddlers change (you could thus do
> paramString.parseParams).
Yes, I think, this would be a nice to have.
> Oh and in answer to your original question, it seems that the list
> macro could benefit from a refresh mechanism. This would mean the
> entire parameter string would be accessible via a params attribute and
> would also update when tiddlers change (you could thus do
> paramString.parseParams).
But it wouldn't solve any of the CSS styling requests, since propper
styling should be done with "class=" and/or "id=" attributes.
Some more thoughts out there?
-m
rakugo
Mar 22, 2011, 5:11:49 AM3/22/11
to TiddlyWiki
I think adding the class "list" and the class "<list-type>" would make
sense like you suggest.
So for the filter list, "list" and "list-filter" would be added as
classes
The list- prefix is probably necessary to avoid any css problems with
existing classes such as "filter" or "all".
With these and parseParams you should be able to do anything in
javascript / css that you would like to do.
sense like you suggest.
So for the filter list, "list" and "list-filter" would be added as
classes
The list- prefix is probably necessary to avoid any css problems with
existing classes such as "filter" or "all".
With these and parseParams you should be able to do anything in
javascript / css that you would like to do.
Reply all
Reply to author
Forward
0 new messages