Xweb first thoughts

Sadly not, just ‘Save and send to group’, cancel and delete.

It looks like it’s admin-only then.

I don’t see an option to change that.

Jeremy

On Fri, Nov 8, 2019 at 03:11 AM, Jeremy Hughes wrote:

Xway (in contrast to Freeway) tries to avoid being excessively modal, and sheets are a modal option - you can’t do anything else in that document until you dismiss the sheet.

If a separate window were opened for the text, rather than an NSPanel, would that still be modal?

Edit: Perhaps I’m misinterpreting when I say NSPanel. Perhaps the modality is that you can’t do much (if anything) until the edit is actually committed.)

Hi Rick,

If a separate window were opened for the text, rather than an NSPanel, would that still be modal?

No. Modal just means that you’re locked into a particular view.

But why not use your favourite text editor to edit code? It’s easy to copy and paste, and there are lots of good text editors: BBEdit, Xcode etc.

TextEdit is OK if you don’t have anything else. I sometimes use it to write notes, or to compose text before I paste it into Slack or Facebook.

Jeremy

On Fri, Nov 15, 2019 at 9:49 AM Jeremy Hughes <email@hidden> wrote:

Hi Rick,

If a separate window were opened for the text, rather than an NSPanel, would that still be modal?

No. Modal just means that you’re locked into a particular view.

Expanding on this, a window is not necessarily modal but an issue with a non-modal window for something that is part of a document, is that it can become non-obvious which document such a window is associated with.

A user might have a window with multiple document tabs open and/or multiple document windows open. This can introduce the confusion that if a code editor window is opened and then the document tab/window is switched, bringing the code editor to the front might have a different document behind it.

Off the top of my head, this raises some questions that would need to be considered such as:
Should it commit changes when it loses focus?
Should it always bring the corresponding document to the front (behind it) when it gains focus?
Should it be a contextual panel that’s always in front and displays content based on selection? (Press cmd+alt+i in Finder to get an idea of what I mean)
Should it be something else?

In general, my preference is for anything that is part of a document to be a part of that document’s window or closely attached to it. i.e. A part of the document window, a modal sheet if modal is warranted or a popover such as with the Extended Properties + popover.

I suspect what Tim was alluding to (please do correct me if I’m speaking for you erroneously) with opening “a file in an external editor” is to be able to open the markup in one’s preferred editor, probably with syntax highlighting and other useful features, then save and Xway would update the markup. This is quite a handy approach that I’ve seen in similar contexts.

Simon

Gotcha. The semantics with the word Modal.

Copy/paste is of course fine. Allowing launch of an external editor would be a nice addition, but not imperative.

An excellent explanation, Simon. Thanks. I hadn’t really thought it through.

On Fri, Nov 15, 2019 at 07:39 AM, Simon Manning wrote:

I suspect what Tim was alluding to (please do correct me if I’m speaking for you erroneously) with opening “a file in an external editor” is to be able to open the markup in one’s preferred editor, probably with syntax highlighting and other useful features, then save and Xway would update the markup. This is quite a handy approach that I’ve seen in similar contexts.

Exactly Simon. What I want to move away from is the constant need to copy and paste code from an editor into Xway. I can see how this would be fine for most users but copying and pasting more than a few times soon gets rather repetative. I suspect that in future I’d just link an external stylesheet to the page and leave that markup area blank.

I suspect what Tim was alluding to (please do correct me if I’m speaking for you erroneously) with opening “a file in an external editor” is to be able to open the markup in one’s preferred editor, probably with syntax highlighting and other useful features, then save and Xway would update the markup. This is quite a handy approach that I’ve seen in similar contexts.

The comment about trying to be non-modal was a response to Tim’s other suggestion (display a sheet). Opening an external editor seems to me to have similar context issues to the issues you mention in connection with opening a separate window. Another possibility that doesn’t have these issues is that we could have a code view in the main window.

Maybe it’s also worth pointing out that if you want to type directly into the fields, you can make them wider by increasing the width of the Inspector panel.

There isn’t currently a way to make them taller.

Jeremy

On 19 Nov 2019, at 19:41, Jeremy Hughes via Groups.Io jeremy=email@hidden wrote:

Maybe it’s also worth pointing out that if you want to type directly into the fields, you can make them wider by increasing the width of the Inspector panel.

There isn’t currently a way to make them taller.

We could make it so that the height increases in proportion to the width (e.g. making the field wider would also make it taller).

Jeremy

Is there an auto-grow text field control, like you can hack together with JS and a in a Web form? (The idea being that it grows in height to continue to show all entered text (or up to a limit) so that it would only require scrolling vertically if there was a serious amount of code paste-bombed into it.) I haven’t tried this exact field yet, but does it currently allow vertical scrolling? Or is it just a regular text field that ignores line-feeds and just accepts up to some (generous) limit of characters of text?

Walter

On Nov 19, 2019, at 2:49 PM, Jeremy Hughes email@hidden wrote:

On 19 Nov 2019, at 19:41, Jeremy Hughes via Groups.Io jeremy=email@hidden wrote:

Maybe it’s also worth pointing out that if you want to type directly into the fields, you can make them wider by increasing the width of the Inspector panel.

There isn’t currently a way to make them taller.

We could make it so that the height increases in proportion to the width (e.g. making the field wider would also make it taller).

Jeremy

On 19 Nov 2019, at 19:52, Walter Lee Davis email@hidden wrote:

Is there an auto-grow text field control, like you can hack together with JS and a in a Web form? (The idea being that it grows in height to continue to show all entered text (or up to a limit) so that it would only require scrolling vertically if there was a serious amount of code paste-bombed into it.) I haven’t tried this exact field yet, but does it currently allow vertical scrolling? Or is it just a regular text field that ignores line-feeds and just accepts up to some (generous) limit of characters of text?

It’s a text view (NSTextView) rather than a text field (NSTextField). Text fields are simplified text views.

We had “stretchy” (auto-grow) text fields in Freeway (e.g. Title field in the Inspector palette) - but they weren’t standard controls.

Xway’s markup views do allow vertical scrolling.

Jeremy

after trying this for some time, i do realy think i can build my websites faster and easyer, now lets wait for the ftp thing in xway so i can make some real sites with this