[TW2036] Planning for v5.4.0

#105

I think you will be astonished how view lines of code that actually is. It is 309 loc (lines of code) → 10.5kByte including comments.

  • 2/3 of it can not be removed, because it is initialising, loading and rendering of the canvas in edit mode
    • Edit mode is necessary to be able to define type and fields
  • IMO rotating an image without modifying it is mandatory and can not be removed
  • Resizing an image is needed and can not be removed
  • At line 225 the “touch” and “mouse” handling starts
  • At line 325 is the save mechanism which needs to stay

So the only code that can be removed or “moved into a plugin” is about 90 locs. If we say the average line length is 50 characters, we can safe 4500 character.

  • The edit-toolbar has 9 icons. 4 of them could be moved into a plugin.
  • 4 toolbar buttons have dropdowns
    • colour picker (used for 2 buttons) … 46 loc → 3kB
    • Opacity dropdown … 32 loc → 1kB
    • Line width dropdown … 25 loc → 1kB
  • Icon SVGs
    • Line width → 0.5kB
    • Opacity icon → 1.2kB
    • Paint icon → 0.9kB
    • Eraser icon → 0.5kB

So we can safe: 12.6kByte in the core if we remove the icons from the core. Which means they are not available for users without installing a plugin.

A plugin for 4 icons and 3 wikitext templates and 90 lines of code → IMO that’s not worth it, since core plugins need extra maintenance work.

Especially, since we remove simple very light weight sketching functionality from the app.

You are right. Images done wrong can have a huge impact on wiki size. So telling users, how they should use and optimise images, is worth wile. There is a pending PR at GitHub that will make the wiki at tiddlywiki.com smaller by 2000kB.

IMO that’s worth it. Removing basic drawing functionality and winning 13kByte isn’t.

No offence intended.

#106

First off; absolutely no offence taken, on the contrary you are clearly enlightening me with information (and some opinions). Thank you, if anything.

Regarding the unmovable parts in the drawing tool and how 2/3 creates the canvas - but the point is that someone who wants a drawing tool would import one which presumably features the canvas aspects. Those who don’t want a drawing tool also don’t need the “loading and rendering of the canvas”.

BUT, I believe this request was already answered elsewhere where Jeremy explained that supportability is a prime objective in TW and, implied, that it would not be possible to support what I request here. So for 5.4.0 my interpretation is that the answer is “no”.

#107

It would be fantastic if the CSS in TiddlyWiki v5.4.0 could utilize modern CSS3, as these features are well-established and supported by all major browsers.

I think both Vanilla and Snow White themes should be retired, and a new minimal, maintainable, and hackable base theme should be introduced, using standard CSS3 rules, functions and classes.

It looks like Jeremy (@jeremyruston) has already begun working on a new color handling code for TiddlyWiki, which will hopefully be included in TW v5.4.0.

3 Likes
#108

Anything to MODULARIZE the CSS in TW would make a lot of difference.

At the moment it is far too difficult to trace which CSS is doing what.
The main stylesheet is too monolithic to use easily.

Two cents, TT

4 Likes
#109

You need to be more specific here. Which features do you refer to?

There is no CSS3 there will never be a CSS4 – Now CSS Modules have a level.

#110

I think, @pmario, you are right.

As far as my use goes the existing TW CSS is very good.

My issue is simple. Vanilla is huge. It is extremely difficult to get good at understanding it.

IMO either modularization OR more logical sectioning by comments would help users a lot,

2 Likes
#111

It should be CSS Snapshot 2017, and perhaps also some new CSS properties and functions, because using @support to check CSS properties for fallback is supported in browsers released after 2015.

https://www.w3.org/TR/css-2017/

1 Like
#112

I find this idea both unnecessary and going backwards except to support newer operators in the mathematics space and think another approach could be found that add the functionality without destroying the current approach. But we can have our cake and eat it to.

Why do I say this?. Outside maths operators deduplication actually make sense for regular users. If I build a list from a set of filter runs my intention is usually to build a list of unique tiddler titles then act on each of these once. Uniqueness is something I expect, not an option.

  • Filters are primarily for titles of tiddlers and these nearly allways unique

Sure there will be great value in being able to use a filter where duplicates are not removed, but I am not sure why we can’t find a way to set/switch or add a setting to filters to enable this behaviour.

  • I understand that every filter that currently does deduplication will need to be changed
  • So why not change it to respond to a switch or indicator to that effect?

For example if we are looking at allowing variables to be set inside filters, surly we can introduce one that is interrogated in the filter operators to determine its behaviours, deduplicate or not. This could be set in filters or outside a filter using a pragma or let. this the behaviour can be set for a tiddler, inside the let or as a prefix within a filter.

  • Not deduplicating, is the new behaviour to “let users and designers say thats what they want”. No Changes needed unless you want to use the new behaviour. Set it globally, pragma, variable or in filter.
  • let it be specifically called out regardless
  • perhaps also allow the variable to be set as a paramer \function name(unique:no) filter

eg [set:unique[no]] or [set:unique[yes]] with yes default as is current. This would set the variable “unique” to the value and inside the filteroperators they would respect this.

  • In this example the set will not produce or interfear with the titles in the filter
  • Perhaps add parenthisis for this (set:unique[no]) or (set:unique[yes]) and allow the value to be a literal, variable or reference. For example (set:pi<pi10>) or more likely (set:places[2]) and later in the filter you can use <places> however you wish. Add the set in a seperate filter run etc…
  • Programaticaly in may only be adding the ability for operators to respond to this, if the variable is set, otherwise default. Ans allowing the filter to effectivly act as if wrapped in a $let widget.
1 Like
#113

As in indicated in the update of the OP by Jeremy on May 20th, no changes are planned to the handling of duplicates in filters in v5.4.0.

2 Likes