Line break in cell?

[Bernhard Leicher]

Hello,

I didn't find a way to insert a line break in a cell, something like a
soft line break in Excel (ALT-ENTER). Just wondering wether that's a
works as designed for some good reason that I'm not aware of, or am I
just overlooking something? It would be helpful for e.g. poems or
organizing code snippets to have line breaks in cells.

And btw: TreeSheets is a wonderful and fascinating tool. It's really
getting addictive for organizing information, concepts, and so on...

Regards, Bernhard

[Wouter van Oortmerssen]

Bernhard,

TreeSheets was never meant to contain large amounts of text in a
single cell, hence has formatting options only on a per cell level.

To put something which should be shown as a multiline item into
treesheets, you would create a grid for it such that every line is its
own cell.

Try that on your poems, and see if it makes sense?

If you copy paste text that has hard line breaks from another app,
it will do this automatically.

Wouter

[Morgan Newall]

Hi Wouter,

An amazing tool you have here. I started searched for something in the ballpark of mindmaps that *might/kinda/do-something-like, then found treesheets tucked down an obscure alley.

Wow - awesome tool and awesome implementation.

Just following up on the linebreak request - while I can see the option to change word-wrapping (alt-scroll) there are many times for me that i've wanted to create a deliberate new line (shift-enter, alt-enter), or paragraph, and couldn't.
It *feels* essential as opposed to a new cell (oh lookit that, I just did a new line without realising it). 

This gives the sentence a flow that, for me, is much faster and easier to comprehend.

Any chance you plan on implementing it/have already?

[Wouter van Oortmerssen]

There are no plans for such a feature so far, as the intention is that if you want a line break, you simply use a new cell. TreeSheets cells are not intended to contain long stories, it works best if you keep things short and use the tree structure to express structure. A newline would be possible, but it is a slippery slope, now people will also want formatting changes inside a cell, bullet points inside a cell, etc. It would kind of ruin the simplicity and make the tree structure less useful.

--
You received this message because you are subscribed to the Google Groups "TreeSheets" group.
To unsubscribe from this group and stop receiving emails from it, send an email to treesheets+...@googlegroups.com.
To post to this group, send email to trees...@googlegroups.com.
Visit this group at http://groups.google.com/group/treesheets.
For more options, visit https://groups.google.com/d/optout.

[Morgan Newall]

Hi Wouter,

Thanks for quick reply. 

First up - TreeSheets crashed. I was trying to select multiple cells (CTL click, SHIFT click) inside another cell (INS) while in (ALT-3) layout.

Problem signature:

  Problem Event Name: APPCRASH

  Application Name: TreeSheets.exe

  Application Version: 0.0.0.0

  Application Timestamp: 543420ba

  Fault Module Name: TreeSheets.exe

  Fault Module Version: 0.0.0.0

  Fault Module Timestamp: 543420ba

  Exception Code: c0000005

  Exception Offset: 0000eb83

  OS Version: 6.1.7601.2.1.0.256.1

  Locale ID: 1033

  Additional Information 1: 0a9e

  Additional Information 2: 0a9e372d3b4ad19135b953a78882e789

  Additional Information 3: 0a9e

  Additional Information 4: 0a9e372d3b4ad19135b953a78882e789

Re: Line Breaks

I can understand your principles re not having formatting, and preserving the call structure, yet from my perspective there seems to be many existing contradictions (or compromises?) to this principle already:

• Bold, italic, typewriter, underlined, strikethrough (all of which IMHO are less fundamental than line breaks)
  
• Increase/reduce text size
  
• All of the layout render style options are stylistic, for visual comprehension are they not?
  

I think these are all very useful features, BTW, yet I perceive linebreaks as more fundamental in achieving the same aims.

I keep thinking of a page of Haikus (or any short poem, or writing, treatments, etc), as an example. 

Picture a page of poems/story/scene ideas, if comparing these different pieces of writing against each other they must at present by separated by lines. 

Snow-obscured heights;
mist-shrouded slopes:
this spring evening. 

For me I find this breaks and disrespects the integrity of a flow of words (yes this MAY just be a personal annoyance - but i'm fighting for the rights of words!), 

Yet having linebreaks would also add a number of different visual cues not possible presently.

The lines breaking a flow of words could denote sections, stanzas, that need work/refinement, with the unbroken linebroken sections as signed-off (or vice versa).

This is just a simple example, yet adding such a simple function could open up a whole number of related features for such a simple functional addition.

Surely that's gotta be programmatical bang for buck!?

Let me know your thougthts - I still love your workl!

Morgan

--
You received this message because you are subscribed to a topic in the Google Groups "TreeSheets" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/treesheets/SRuEGetFiMM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to treesheets+...@googlegroups.com.

[awol]

I would love hard returns. Now I use punctuation and extra spaces as a workaround for hard returns. Is that better? I don't think so. Same goes for bold, underscore, italic.

Assuming, of course, that it soesn't add to the weight of the program. I don't think it is against the fundamental logic of the program; it would expand it in an integral way.

I think TreeSheets deserves this growth. Let us take responsibility to use intracell formatting wisely. Even spreadsheets now allow intracell formatting and hard returns (I just checked LibreOffice).

Come on, Wouter, give us a break!

[Wouter van Oortmerssen]

Morgan,

First up - TreeSheets crashed. I was trying to select multiple cells (CTL click, SHIFT click) inside another cell (INS) while in (ALT-3) layout.

Problem signature:

  Problem Event Name: APPCRASH

  Application Name: TreeSheets.exe

  Application Version: 0.0.0.0

  Application Timestamp: 543420ba

  Fault Module Name: TreeSheets.exe

  Fault Module Version: 0.0.0.0

  Fault Module Timestamp: 543420ba

  Exception Code: c0000005

  Exception Offset: 0000eb83

  OS Version: 6.1.7601.2.1.0.256.1

  Locale ID: 1033

  Additional Information 1: 0a9e

  Additional Information 2: 0a9e372d3b4ad19135b953a78882e789

  Additional Information 3: 0a9e

  Additional Information 4: 0a9e372d3b4ad19135b953a78882e789

That sadly says nothing. Can you please try and see if you find reproduction steps for this? I take crash bugs very seriously.

 

Re: Line Breaks

I can understand your principles re not having formatting, and preserving the call structure, yet from my perspective there seems to be many existing contradictions (or compromises?) to this principle already:

• Bold, italic, typewriter, underlined, strikethrough (all of which IMHO are less fundamental than line breaks)
  
• Increase/reduce text size
  
• All of the layout render style options are stylistic, for visual comprehension are they not?
  

All of these work on per cell basis, which is entirely consistent with the design.

 

I think these are all very useful features, BTW, yet I perceive linebreaks as more fundamental in achieving the same aims.

What is it exactly about a line-break that is better than a cell-break?

 

I keep thinking of a page of Haikus (or any short poem, or writing, treatments, etc), as an example. 

Picture a page of poems/story/scene ideas, if comparing these different pieces of writing against each other they must at present by separated by lines. 

Snow-obscured heights;
mist-shrouded slopes:
this spring evening. 

For me I find this breaks and disrespects the integrity of a flow of words (yes this MAY just be a personal annoyance - but i'm fighting for the rights of words!), 

Yet having linebreaks would also add a number of different visual cues not possible presently.

The lines breaking a flow of words could denote sections, stanzas, that need work/refinement, with the unbroken linebroken sections as signed-off (or vice versa).

This is just a simple example, yet adding such a simple function could open up a whole number of related features for such a simple functional addition.

Surely that's gotta be programmatical bang for buck!?

It isn't always about the programming time. I am trying to keep my UI consistent.

[Wouter van Oortmerssen]

Same question to you: what is the problem with using multiple cells instead?

[Morgan Newall]

Hey Wouter,

To try to tell you more re the crash - my intention was to select different cells, like you can in spreadsheets, to change their font size independent to the other rows.

If you look at the image pasted below, imagine the inner most cell had 3 lines instead of 2 - I try to CTL-Click select rows 1 & 3 - CRASH. I can't reproduce it now.

On 15 October 2014 03:13, Wouter van Oortmerssen <aard...@gmail.com> wrote:

All of these work on per cell basis, which is entirely consistent with the design.

I don't actually understand the logic here. 

Yes it is consistent with a design where you have every line forced to be bound by a cell. But is that really saying anything? 

What's the purpose of this design?

What we're bringing up here is that, to us, this design does not seem consistent with the aims of the program (esp given you provide various other stylistic and formatting options).

 

I think these are all very useful features, BTW, yet I perceive linebreaks as more fundamental in achieving the same aims.

What is it exactly about a line-break that is better than a cell-break?

The question answers itself really:

A line-break is unbroken, a cell break is broken.

Having sentences above and below (with space, not lines) provides visual clarity that the line above &/or below are linked.

It also allows one to create blank space (empty line paragraphs) above &/or below, that's not possible currently.

The below could be done with a linebreak, and 1 box, instead of 3.
Most often simpler is better.

For me it's not an argument about EITHER/OR, for me the point is that having BOTH line-breaks and cell breaks allow so many more simple options, that are in the spirit of the current program.

[awol]

Bravo, Morgan.

Wouter, having the option to format within a cell makes TreeSheets a richner medium for expression, allows the product to track the thought and feeling the author is using the tool to express.

I gravitate to the tool that I can use without thinking about how to use it when I'm writing, and that intrudes the least when I am reading the result. Too many cells is unnecessarily intrusive, and not having the choice does not make it any easier or more intuitive to use when writing.

Another take: you have added more dimensionality to the sheet model. This would add yet another dimension. I really can't see how adding formatting would break your model; I do see how it would amplify it.

As I said in a prior post, intracell formatting has already been added to the LibreOffice spreadsheet, so I assume it is in common use. TreeSheets now looks a little dated.

Allen

[Wouter van Oortmerssen]

I have no doubt that formatting within a cell would be useful to some, and that it would enhance the programs overall capabilities. But besides complicating the UI, it would really complicate the code too. I personally also feel that it is inconsistent, because you would have two ways, and two levels to accomplish the same structuring/formatting.

Given how little time I can invest in TreeSheets at the moment, this doesn't seem like a good tradeoff. But given that it is open source, my opinion is not the end of where TreeSheets should go. Someone else can try this, and if it is clean enough, could be added to TreeSheets, or otherwise live on as a fork.

[awol]

Wouter,

Fair enough. I understand it would be a fundamental change.

What you have done already stands on its own, of course, and I think the way you have implemented >2-dimensinality really works well.

Allen

[Morgan Newall]

I also appreciate that there are different strokes for different folks.

Wouter  - could you give a few examples as to how you achieve the same ends as a linebreak.

I.e. Embed cell within cell, other options?

Morgan Newall, Video Alchemist

Mob: 0414 841 969 | Email: mor...@reelists.com.au

thereelists

--
You received this message because you are subscribed to a topic in the Google Groups "TreeSheets" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/treesheets/SRuEGetFiMM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to treesheets+...@googlegroups.com.

[Wouter van Oortmerssen]

Wouter  - could you give a few examples as to how you achieve the same ends as a linebreak.

I.e. Embed cell within cell, other options?

No, I would simply put paragraphs in adjacent cells (the cell below). If necessary, first "wrap in new parent" (F9). 

[Morgan Newall]

Sorry, I missed how to create a paragraph?

--

[tpkyteroo luebeck]

What I do is INSERT GRID, where I want my paragraph, then I 

type line one here until I want line break ENTER

type line two until done ENTER

type line three ENTER

type line four until done ENTER

type line five here until want I line break ENTER

This is what I do. 

[tpkyteroo luebeck]

What I've done is this. 

Chose Cell.

Right click Choose Insert New Grid

Wrap in new parent. 

Click on Right Line of "New Parent" square.

Right Click Choose Insert New Grid. 

This should give you [ [_] [_] ]  look. with all the top lines also in. I did try it making new parent first, and I got a mess. 

Then, you type inside the lett square, hitting enter when you want a line break, 

Keep typing, Enter until you get as much paragraph as you want over there. 

Then type in the right square, and Enter when you want a line break. and keep typing until 

its how  you want it. 

[tpkyteroo luebeck]

 If I could edit, I would. 

If you Wrap in New Parent

Then type, enter

then click on Right line, you can type enter. But then you'd have to click on the box below to type more. 

This is why I put both paragraphs inside a grid. In this way I can just type, Enter, type enter and get it done faster. 

See my [ [_] [_] ] post. 

[Andrew F.]

Hi, I'm new to the forum, having discovered TreeSheets recently.

I'd like to throw my hat in the ring regarding alt+enter for newline.

I appreciate the desire to keep TreeSheets focused on text organization rather than text formatting.  It's not a word processor.  For writers, it's what you use before you switch to your word processor.  Even so, being able to insert a carriage return (paragraphs) in a cell would greatly improve cell text layout.  It feels needlessly complex to require creating sub-cells when all you want to do is have a cell heading of a few words, a blank line, then the cell body text.  Like how people use index cards: scribble a brief heading then follow with the body text.  But, again, I understand the desire to limit text to a single, simple chunk.

As a rapid organizer, TreeSheets can't be beat.  Thank you for this wonderful and intuitive writing tool.

[dahn oak]

Thu, 31 Dec 2015 03:24:19 -0800 (PST)
"Andrew F." <gmc...@gmail.com>:
> [...]

> I appreciate the desire to keep TreeSheets focused on text organization
> rather than text formatting. It's not a word processor. For writers, it's

> what you use *before* you switch to your word processor. Even so, being

> able to insert a carriage return (paragraphs) in a cell would greatly
> improve cell text layout. It feels needlessly complex to require creating
> sub-cells when all you want to do is have a cell heading of a few words, a
> blank line, then the cell body text. Like how people use index cards:
> scribble a brief heading then follow with the body text. But, again, I
> understand the desire to limit text to a single, simple chunk.

> [...]
I aggre with you, Andrew, nevertheless I think it would be better to have
minimal set of word processing features and ineed line break is the most
important one. I code usually and learn to, so very frequently I have a need
to organize small snippets of code that illustrates some simple use case of a
programming language, but unfortunately Treesheets is not convenient for that
(yet, I hope). Looking forward for more community thoughts on this issue.

───────────────────────────────────
dahn oak <danylo....@gmail.com>

[Wouter van Oortmerssen]

I would like to understand what you guys have against using cells as paragraphs (as intended).

For example, if you want a heading with a body, you typically go:

(type heading) INS (type body)

Which visually gives you the separation you want.

Or if you want two equal paragraphs:

(type paragraph1) ENTER (type paragraph2)

Which gives you two cells above/below eachother.

You can even go in reverse, if you want some structure:

(type body) F9 (type heading)

This allows you to create the content before you have even decided it needs a heading.

You can do the same with multiple existing paragraphs using drag-select.

Why do you prefer not to use the above tools?

As mentioned before, allowing a hard-return inside a cell now gives two competing ways to sequence paragraphs: cells vs hard-returns. Except the former has all formatting and arranging tools that TreeSheets already has, and the latter has.. none.

--

You received this message because you are subscribed to the Google Groups "TreeSheets" group.

To unsubscribe from this group and stop receiving emails from it, send an email to treesheets+...@googlegroups.com.

To post to this group, send email to trees...@googlegroups.com.

Visit this group at https://groups.google.com/group/treesheets.

[Andrew F.]

Hi, Wouter.

I've found a way to achieve a look and feel that simulates working with index cards.  Now I have no need for a paragraph break.  Take a look at this screenshot, then I'll explain...

http://i.imgur.com/ZPlB2L7.png

For me, the key thing was being able to hide the sub-cell border.

Because I wanted to treat a cell like an index card and treat its sub-cells as paragraphs, I needed to get rid of the sub-cell border.  As far as I know, there is no option to turn off a cell border, only an option to change its color.  Therefore my only option to 'hide' a cell border is to change the border color to match the parent cell's background color -- as I've done with the first two parent cells (index cards) in the screenshot.

Because inserting sub-cells retains the cell background of the parent cell, the only tweak I have to make after hitting INSERT to create the "index-card body" text is to return to the parent and set the border color to match the background color.  Which brings me to my next point...

"Set border color" does not work the way I thought it would.  Normally a "set border color" function operates on the active cell, i.e. is sets the border color for the border surrounding the selected cell (think Microsoft Excel).  It does not work this way in TreeSpace -- at least not for my Ubuntu install.  Instead, it sets the border color for any child cells within the selected cell.  This threw me earlier when I was trying to figure out a way to remove the sub-cell borders to achieve the look I finally got in the screenshot.  I was selecting the sub-cells (the "paragraphs") and changing the border property to match the parent cell background color, expecting the border to disappear -- but it would not change.  So I just assumed the border-color setting wasn't working for some reason.  I only stumbled on the way border color works -- as described above -- today, thankfully!

A 'hide border' setting for cells would save me the trouble of having to manually reset the border color ever time I create a new sub-cell.  It makes sense in grid view, but probably makes no sense for line/bubble view.  In grid view there's always the dotted border to show cell boundaries, even when you remove/hide the border, so you can always tell where the cell boundaries lie, no matter the nesting.  Anyway, I can now easily enough achieve the index-card look I prefer to work with when outlining/brainstorming my writing projects.  Thanks!

Regards,
Andrew F.

[Wouter van Oortmerssen]

Hah, well that's a good trick!

Grids are part of a cell, so most operations that work on the whole grid work on the cell that contains them. Since you can't change the border of an individual cell (different from the cells it sits next to), it would be inconsistent to allow it to be changed from there. But yes, that's different from Excel.

Another tool you might find helpful is to set "Grid Border Width" to 1, to make it less visually apparent. Actually could add an option for it to be 0, which would be the same as turning it off.

--

[Wouter van Oortmerssen]

Just added a way to set the border size to 0 (and keyboard shortcuts): https://github.com/aardappel/treesheets/commit/eda8696a326765efeaec3752af08cdd134ad3a55

[Andrew F.]

Thanks!  Looking forward to the new zero-border.  I'm happy to be a tester for new builds (.deb and .exe) if you need it.  Not much testing required for this tiny code change, I would think, looking at your commit.  But I'm ready and able to lend a hand for future updates.

[Wouter van Oortmerssen]

Thanks for the offer. There are no such things as test builds (or stable builds for that matter), all my changes go straight in the main product, and so far that hasn't caused any problems.

[dahn oak]

In my case I'm disturbed by the inner cell border, especially when using black
background (and I use it a lot). It's too bright and distracting, although very
thin. I'd like to have an option to manage it's colour and thickness as in
cell border.

Btw, it's still possible to write several paragraphs in one cell using unicode
x2029 character (paragraph separator). On Linux type Ctrl+Shift+u+2029. But it
rather a hack, you'll break text carret behaviour and selection for the cell
with this character.

Thu, 31 Dec 2015 13:39:06 -0800
Wouter van Oortmerssen <aard...@gmail.com>:

──
dahn oak <danylo....@gmail.com>

[Wouter van Oortmerssen]

Yeah, I guess that inner cell border assumes you're using a light-ish background.

[dahn oak]

Yes, and bubble layout too: as it's derkening the bgcolor, bubbled black
remains black :)

Tue, 9 Feb 2016 11:47:05 -0800

[Jean]

A Cell Split, complementing the already existing Cell Merge, would address some of those issues while remaining consistent with the overall TS UI.