do you think it's time for a "bare bones" edition?

[Rustem]

I've had a bit of a discussion over at GitHub, that made me think...

Right now TiddlyWiki is still failrly basic as it is. But with the influx of new features, there will be more and more people wanting things to look one way or the other.

I am comfortable with customizing the interface of my wiki on my own, plus I don't feel like arguing my point of view to death. But when it comes to modifying/adding the deeper internals of TiddlyWiki, I still completely rely on what is delivered by Jeremy.

So, I thought it would be nice if there was a "bare-bones" edition of TiddlyWiki. It would let me enjoy all the latest improvements to the "core core", without having to struggle with the ever-increasing number of "bells and whistles" in order to keep my wiki looking just the way I like it.

--R.

[Hegart Dmishiv]

OMG, that's just what I said in GitHub, as you were posting here in the discussion forums. Great minds think alike!

[Rustem]

LOL and wow! And thank you ;) I agree with that last observation.

[Hegart Dmishiv]

Funny how an experienced user like yourself, and a complete n00b like me, can come up with the same answer, from different perspectives.

[Tobias Beer]

Hi Rustem,

I like that, and I think it goes hand in hand with Mario's suggestion to outsouce the controlpanel into a plugin.

Chances are, after you've configured your wiki, you'll never touch that again, so out with it.

These types of micro-optimizations, including minification,

will surely increase responsiveness of it all,

especially when served over the web as a kind of website.

Best wishes,

— tb

[Jeremy Ruston]

> But with the influx of new features, there will be more and more people wanting things to look one way or the other.

The new folding features don't make any visible difference unless they are explicitly switched on. That's consistent with my general policy: I don't plan on making major changes to the basic UI of TiddlyWiki unless those changes simplify the UI. New features will always be off by default; I want there to be some consistency between versions.

> So, I thought it would be nice if there was a "bare-bones" edition of TiddlyWiki. It would let me enjoy all the latest improvements to the "core core", without having to struggle with the ever-increasing number of "bells and whistles" in order to keep my wiki looking just the way I like it.

First, to emphasise what I've just said: backwards compatibility is a major goal for onward TiddlyWiki development. If you have to "struggle" with the new "bells and whistles" then we'll have failed in that objective.

Anyhow, I think that what you mean in functional terms is a replacement core plugin that excludes some tiddlers.

The tiddlers in the core at the moment include the following categories:

* icon images

* en-GB user interface text

* JavaScript code modules

* templates

* configuration tiddlers

Technically, almost all of those tiddlers can be excluded and leave us with a functioning TiddlyWiki. That's the payback for the rigorous modularity of TiddlyWiki: there's a small-ish boot kernel and then everything else is, in a sense, optional.

Before even considering which tiddlers might be excluded, it's worth exploring the motivation here:

* If it is to reduce the size of the core plugin, we can do that more effectively by exploring packing the code

* If it is to simplify the UI, there's already nothing to stop people replacing $:/PageTemplate with their own complete user interface that only dips into the "stock" user interface when required

So, as I've said before, I worry that this discussion will devolve into a long debate about which shadow tiddlers to omit, without there being a really clear practical payback for all that effort.

Anyhow, it is very easy for anyone to experiment with alternative core plugins.

Under Node.js, one could create a new plugin that uses tiddlywiki.files to explicitly include only the core tiddlers that are required. One would want to automatically generate the tiddlywiki.files content, but that would be easy enough.

In the browser, one could write code that reads a shadow tiddler list from a config tiddler and then generates a slimmed down core plugin with only those fields. A special save template could be used to save a copy of the wiki with the alternative core loaded.

Best wishes

Jeremy.

On Sat, Sep 19, 2015 at 12:25 AM, Tobias Beer <beert...@gmail.com> wrote:

Hi Rustem,

I like that, and I think it goes hand in hand with Mario's suggestion to outsouce the controlpanel into a plugin.

Chances are, after you've configured your wiki, you'll never touch that again, so out with it.

These types of micro-optimizations, including minification

will surely add to speed over the web.

Best wishes,

— tb

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/ab49223e-969e-42b1-9431-5b96e46cfa1f%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Jeremy Ruston
mailto:jeremy...@gmail.com

[Andreas Hahn]

Hi Jeremy,

I do agree with you and I do not want to spark a long debate, I do
however have a questions concerning this:

Am 19.09.2015 um 13:21 schrieb Jeremy Ruston:
> * If it is to simplify the UI, there's already nothing to stop people
> replacing $:/PageTemplate with their own complete user interface that
> only dips into the "stock" user interface when required

Do you think it would be worth separating the UI (templates) from the
rest of the core, so that there are then 2 core plugins, namely $:/core
and $:/ui. I am not certain if the ties between the two are really that
easy, but might open a way for slimmer and alternative UI "plugins".
Also people might chose to update the core (due to bugfixes), but not
the UI (no new fancy features), which in an ideal backwards
compatability way *might* work (*waving hands, again I don't know how
interconnected the UI actually is with the rest of the core modules*).

/Andreas

[Jeremy Ruston]

Hi Andreas

Do you think it would be worth separating the UI (templates) from the rest of the core, so that there are then 2 core plugins, namely $:/core and $:/ui. I am not certain if the ties between the two are really that easy, but might open a way for slimmer and alternative UI "plugins". Also people might chose to update the core (due to bugfixes), but not the UI (no new fancy features), which in an ideal backwards compatability way *might* work (*waving hands, again I don't know how interconnected the UI actually is with the rest of the core modules*).

That last point is tricky: I wouldn't like to have to support mismatched versions of $:/core and $:/ui. I think that would be a debilitating constraint on development.

Otherwise, yes, such a split could be done. If you search the core/modules directory for the string $:/ you'll see the dependencies between the core JS code and actual tiddler and tag names; there's not actually that many.

But again, I'd ask for the motivation. If it's about reducing file size, then I think there are other options that have less impact on the complexity of the project. If it's about being able to ignore the core UI then I'd respond that that is already possible.

Just to be clear, my stand on this is that I'll help anyone who wants to experiment, but I don't see how I can justify working on this (which is quite demanding) for dubious benefit when we've got major issues like poor multi-user behaviour to work on.

Best wishes

Jeremy.

 

/Andreas

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/55FD4C01.5020402%40googlemail.com.

For more options, visit https://groups.google.com/d/optout.

[Tobias Beer]

Hi Jeremy,

I agree on all points / concerns... but I also share the interest Andreas expressed in separating core and ui... which is something that TW2 fell short rather categorically. I like the fact that one could with a bit of fiddling compile a desired minimal TW5 already.

I can see how this is not a priority (atm), albeit a worthy endeavor that anyone who wishes to explore alternative ui's for TiddlyWiki can pick up on and, like Felix for TiddlyMap, then make necessary pull requests to the core that could eventually lead to rigorously separating core and ui... with someone else taking up the task of developing and testing all that.

As for mismatching versions, there could always be a dependency of a given ui version to a given core version. Not?

Best wishes,

— tb

[Andreas Hahn]

Am 19.09.2015 um 13:59 schrieb Jeremy Ruston:
> Otherwise, yes, such a split could be done. If you search the
> core/modules directory for the string $:/ you'll see the dependencies
> between the core JS code and actual tiddler and tag names; there's not
> actually that many.
>
> But again, I'd ask for the motivation. If it's about reducing file
> size, then I think there are other options that have less impact on
> the complexity of the project. If it's about being able to ignore the
> core UI then I'd respond that that is already possible.
>
> Just to be clear, my stand on this is that I'll help anyone who wants
> to experiment, but I don't see how I can justify working on this
> (which is quite demanding) for dubious benefit when we've got major
> issues like poor multi-user behaviour to work on.

I was in no way implying that you should work on this, but I was
interested in how one would go about completely changing the UI (think
applications on top of the TW core) and which and how many ties would
have to be kept intact for TW to continue to work. So you answered both
of those, thanks for taking the time =).

/Andreas

[Jeremy Ruston]

Hi Tobias

> that could eventually lead to rigorously separating core and ui

The core JS code and the UI are already rigorously separated into different types of tiddler. There's plenty of modularity at that level. 

> As for mismatching versions, there could always be a dependency of a given ui version to a given core version. Not?

No. I was responding to the suggestion that users should be able to run different versions of the UI against the core.

> albeit a worthy endeavor that anyone who wishes to explore alternative ui's for TiddlyWiki can pick up

It's a *terrible* endeavour for anyone who wants to explore alternative UIs. It's not an obstacle to exploring alternative UIs, and so it's just a plumbing task that would prevent them from actually developing the alternative UI.

Best wishes

Jeremy.

/Andreas

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/55FD55F0.8070407%40googlemail.com.

For more options, visit https://groups.google.com/d/optout.

[BJ]

I think that breaking the core into separately managed components would be a disaster for plugin writers - there has to be only one version that you work to override. I do think that the template tree is a bit too ridged - although there is are configuating options there are not really any 'hooks' to include alternative templates while leaving the current templates in place. Also macros could be used instead of widgets in the templates, maybe the widget tree (is?) could be more hackable. Also there is no way to set global defaults for widgets. (the defaults are defined in the widgets).

cheers
BJ

[Tobias Beer]

Hi Jeremy,

 

I was responding to the suggestion that users should be able to run different versions of the UI against the core.

Of course, I guess I ignored that fact. I agree that that would not be advisable.
 

It's a *terrible* endeavour for anyone who wants to explore alternative UIs. It's not an obstacle to exploring alternative UIs, and so it's just a plumbing task that would prevent them from actually developing the alternative UI.

Starting from a custom pagetemplate is the way to explore, yes. Throwing out the default ui would be rather an attempt for optimization. Not sure about the themes, though. Haven't tested yet, how much "starting from scratch" is actually possible ...or what that looks like.

Best wishes,

— tb

[Danielo Rodríguez]

Hello Jeremy,

You said several times that it is very easy to anyone to "slim" it's own version of tiddlywiky. I'm not only think that it is not so easy,I don't even know how to start. I think this modularity makes sense. Other frameworks (or libs) suffers from the same problem, like JQuery and people ends using other more modular libs like zepto.

Regards

[PMario]

On Monday, September 21, 2015 at 6:25:38 PM UTC+2, Danielo Rodríguez wrote:

You said several times that it is very easy to anyone to "slim" it's own version  of tiddlywiky. I'm not only think that it is not so easy,I don't even know how to start.

It actually is that easy. You just need to start with a new PageTemplate. ... The reason, why it looks complicated is, that the TW UI was developed over 36 releases now. A hell lot of improvements and new features have been added. Not speaking about the bug fixes ;) It's about 4+ years of development. .. And that's a lot of work, to do, if you want to start from scratch. So it's overwhelming, but it's an easy concept. Use the widgets and every single feature of them in the right way ;)

eg: Language switching support, optional layout elements and so on, have improved the usability for the standard user. So we now have a "basic" layout for users but "basic" doesn't mean "it's simple for developers". ... No user cares if something is simple for developers. It needs to be simple for "end users" ...

BUT

With TW many "endusers" become "developers". That's cool! It makes TW unique. ... But it also means, that there is a very steep learning curve. .. If you want to start a new UI from scratch it means, you need to dig into the existing UI and understand, how Jeremy created the existing UI. IMO it's simple, but it's a looooooot of work. And that makes it look complicated.

-mario

[Tobias Beer]

Hi Mario,

 

With TW many "endusers" become "developers". That's cool! It makes TW unique. ... But it also means, that there is a very steep learning curve. .. If you want to start a new UI from scratch it means, you need to dig into the existing UI and understand, how Jeremy created the existing UI. IMO it's simple, but it's a looooooot of work. And that makes it look complicated.

The main intention of any "bare-bones" edition — as I see it —  would probably not be to create alternative wiki-ui's, but to have a bare core that runs smoothly, ui-less that is (less ui) ...and then a step by step implementation of things maybe a published "site" might need, a result that is not meant to be edited like TW, however TW perhaps being the editing environmnent that created it, perhaps using node.

If you wish, not a static site, but not a full-blown TW either. Something that comes with little to no styling and might hook things like jQuery or other libraries to do things you wouldn't do in TiddlyWiki but now you can, since nobody is stealing your DOM any longer.

It could even simply be something as simple as an alternative save-filter.

Another way to go about doing things "publishing" would be to focus on improving static sites. There are many paths that lead to ...being busy working things out. ^_^

And also, "bare-bones" possibly means quite different things to different people.

Jeremy ought to stay focused on the code that makes Tiddlywiki work with respect to the latest browsers and the latest browser versions. 

Surely. Not every question or idea means "Jeremy, would you please." ...a simple "you can try this and that, but I probably won't", and that's good enough an answer.

Best wishes,

— tb

[BJ]

Jeremy has done an amazing job making tiddlywiki very efficient with the modules that it uses - the code is very efficient. If the functionality were constructed from node.js modules tiddlywiki would be much larger. The case for splitting the core into smaller units is for using it in applications other than a tiddlywiki, eg making other types of single page apps, which might not need to save themselves.

[Eric Shulman]

On Monday, September 21, 2015 at 12:30:38 PM UTC-7, Pete Johnson wrote:

Tiddlywiki already comes "barebones."

The ongoing discussion suggests that some people think otherwise.  As Tobias noted, "bare-bones" possibly means quite different things to different people.

I think this discussion (and any actionable items that result) is part of what has made TiddlyWiki so versatile.

 

Jeremy produces an amazing free product.

Yes, he does.

 

For those who don't like to advance, they can keep copies of empty Tiddlywikis of the versions they like.

"like to"... "want to"... "need to".... pick any verb that fits your situation... 

No one forces anyone to upgrade to the latest Tiddlywiki.

The discussion about what a "barebones" TiddlyWiki could/should be has little to do with upgrading.  It's more about how to package the underlying the functionality TW core so it can be used in other scenarios, independent of the default interface delivered with the standard distro.

 

Browsers change. Browser makers change Javascript engines. Browsers don't stand still. 

Yes.  The technology that enables TiddlyWiki to work changes over time.  That is one of the primary reasons that TW5 was created... the old TiddlyWiki "Classic" codebase was based on 2005-era methods and script engines, and it was becoming increasingly difficult to maintain because of "browser drift".  A fresh start, using "modern" coding methods and functionality was the inevitable response. 

 

Jeremy ought to stay focused on the code that makes Tiddlywiki work with respect to the latest browsers and the latest browser versions. 

Currently, Tiddlywiki has a major error when trying to render with the latest version of Chrome through http. All should rather see Jeremy work to fix those kinds of errors rather than appeasing one-off requests.

I've written about it on the forum here: Internal Javascript Error and the Latest Version of Chrome.

 

I have not been able to reproduce the error you reported.  I am using Chrome Version 45.0.2454.99 m (under Windows 7), and I visited http://TiddlyWiki.com, and there was no error.  Please note that I am not disputing that you are seeing an error message... just that it isn't reproducible for everyone, so it might not be as much of a "major error" as you have suggested.

As far as Jeremy "appeasing one-off requests"... that rarely happens.  Jeremy is famously resistant to "putting stuff into the core" just to support a single use-case.  However, sometimes a single use-case can suggest an area of functionality that has more general applicability, and Jeremy decides to direct some of his attention there.

With regard to the "browser drift" problem noted above, that is only ONE of the many areas of TiddlyWiki that need attention.  Other major areas include:

* improvements/additions to core functionality

* improvements/additions to baseline interface

* efficiency/performance issues

* plugin installation/distribution mechanisms

* documentation

* etc.

Bottom line, while you might feel that fixing the error you encountered should be "priority #1", there are numerous other ongoing efforts that are arguably of greater impact to more people.  Of course, we *do* want to figure out what it happening for you (and *possibly* others), but try to be a bit more patient and look to the TiddlyWiki community itself for help.  If the problem exists for some people but not others, perhaps we can narrow down the conditions under which it occurs by having more people test under a variety of platforms and configurations.

enjoy,

-e

Eric Shulman

ELS Design Studios

TiddlyTools - "Small Tools for Big Ideas!"

InsideTiddlyWiki: The Missing Manuals

YOUR DONATIONS ARE VERY IMPORTANT!

HELP ME TO HELP YOU - MAKE A CONTRIBUTION TO MY "TIP JAR"...

   http://TiddlyTools.github.com/fundraising.html#MakeADonation

Professional TiddlyWiki Consulting Services...

Analysis, Design, and Custom Solutions:

   http://www.TiddlyTools.com/#Contact

[Danielo Rodríguez]

>The discussion about what a "barebones" TiddlyWiki mostly has to do with some looking for another or others to do work on their behalf.

This is a discussion about having a barebones edition. No one is asking others to do their job. Tiddlywiky community has demonstrated to be active and to take the necessary efforts to contribute to the project. Before telling others that they are lazy you would think about it twice.

[Rustem]

On Saturday, September 19, 2015 at 4:21:37 AM UTC-7, Jeremy Ruston wrote:

... I worry that this discussion will devolve into a long debate about which shadow tiddlers to omit ...

You had no idea :)

[Jeremy Ruston]

Tobias said:

> The main intention of any "bare-bones" edition — as I see it —  would probably not be to create alternative wiki-ui's, but to have a bare core that runs smoothly, ui-less that is (less ui) ...and then a step by step implementation of things maybe a published "site" might need, a result that is not meant to be edited like TW, however TW perhaps being the editing environmnent that created it, perhaps using node.

That sounds to me that the goal of the "bare bones" edition is to start again with a simpler UI. That's already do-able without having to fork the core plugin; as discussed above, one just redefines $:/PageTemplate to create a custom UI.

The only goal I'm hearing for the slimmed down core plugin is to save space. As I've said before, there's much easier ways to achieve that goal.

Just imagine that we did create an alternative core plugin that had less in it. Then every change to TW, and every change by every plugin author, would need to be verified in both environments. The workload is terrifying for a project like this.

Best wishes

Jeremy.

[Tobias Beer]

Hi Jeremy,

 

Just imagine that we did create an alternative core plugin that had less in it. Then every change to TW, and every change by every plugin author, would need to be verified in both environments. The workload is terrifying for a project like this.

I totally agree, especially with "bare-bones" being rather losely defined. Answers to "How far can I strip the core down?", depend on what that "core" is that anyone wants left, i.e. its feature-set.

Any bare-bones-build would have to be...

• constructed => here's probably where most feedback would be welcome
  
• documented
• maintained
  
• tested
• supported

...by whomever desires it.

That sounds to me that the goal of the "bare bones" edition is to start again with a simpler UI.

Yes, the details being in all the degrees of "simple", all the way down to "render only".

As I've said before, there's much easier ways to achieve that goal.

Details to that would be what anyone wishing to go down that route would best start with, e.g. stripping out code comments, minifying js, etc... or, alternatively, enhancing static sites with rich components.

~

I totally agree, wishes to have anything like that be part of the core distro are, frankly, unreasonable... unless perhaps there was some Major benefit to that to the core project, which has yet to show up.

Best wishes,

— tb

[Danielo Rodríguez]

For me a bare bones edition should not include images or any widget that is not absolutely essential for TW. Currently the only way to do this currently is by clonning the project and modifying it, and of course you can not use the tiddlywiky you have installed globally.

[Jeremy Ruston]

HI Danielo

For me a bare bones edition should not include images or any widget that is not absolutely essential for TW. Currently the only way to do this currently is by clonning the project and modifying it, and of course you can not use the tiddlywiky you have installed globally.

What would be the benefit of having a bare bones edition? We still seem to be coming back to a desire for the core plugin to be smaller. As I keep saying, the amount of complexity that you are proposing to introduce doesn't seem worth that benefit.

What can you not do today that you would be able to do if there was an alternative, bare-bones version of the core plugin?

Best wishes

Jeremy.

 

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/239d1aa7-427f-4058-b0b3-6b1a14b9bf9d%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.