Kickstarter/yWriter Mac/iPad

[Simon Haynes]

I'm only toying with this idea, but I was considering putting up a Kickstarter project which would involve me getting a Macbook of some description as well as the tools (and skills!) necessary to create a version of yWriter for the Mac and iPad.

Now, at this stage it's just a nebulous what-if maybe probably never type of idea, mostly because I'm flat out writing and programming already.

However, there are quite a few people asking for Mac/iPad versions of my software, and many more who would switch to mac if they could continue to use yWriter properly.

My main concern would be the fact I've not written for the mac before, and I'm pretty sure I'd have to start from the ground up. It could take me a year or more to get a basic alpha version out, and that's a long time to wait for any project.

An alternative would be for me to craft yWriter6 from scratch in a language which is cross-platform, and uses a common toolkit. (E.g. GTK+, as used by the Gimp and others.) I don't think that would fly on the iPad, but I believe it would allow distribution on Android.

It sounds like I need a features grid comparing languages/toolkits/platforms. There's no way I'm coding an application this complex in something like C, for example, which might cut out a few options. On the other hand C# is very close to VB, and would be my second choice.

Regards
Simon Haynes
--
Need help with yWriter?
Check the left hand menu: http://sites.google.com/site/ywritersj/
(Quickstart, getting started, FAQ, user manual, comprehensive help)

Simon Haynes, author and programmer: http://www.spacejock.com
Hal Spacejock sci-fi comedy http://www.spacejock.com.au/Hal1.html
Hal Junior sci-fi for kids http://www.spacejock.com.au/HalJunior.html

[Matthew Rasnake]

Simon,

I am 100% behind this idea. I would gladly kick in on a ground-up
cross platform version if it meant a stable, native Linux version was
a by-product.

There are a few frameworks available now that would let you target
desktops, as well as iOS and android phones and tablets from the same
source. Off the top of my head, I can think of Titanium Studio, and
the newly open-sourced Illumination Software Creator.

I was just extolling the virtues of yWriter to a colleague last week,
and would love to be able to tell people—without reservation—that
yWriter is natively cross platform.


Sent from my iPhone

> --
> You received this message because you are subscribed to the Google Groups "yWriter" group.
> To post to this group, send email to ywr...@googlegroups.com.
> To unsubscribe from this group, send email to ywriter+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/ywriter?hl=en.
>

[Matthew Rasnake]

Just spent more time than I should looking around, and found a few interesting things...

This post ( http://www.dodgycoder.net/2012/01/modern-cross-platform-development.html ) has a great overview of issues and various toolkits & whatnot. The most interesting seem (to me) to be:

http://www.rawmaterialsoftware.com/juce.php

and

http://getmoai.com/products/sdk/

I saw someone else mention Mozilla's XULRunner ( https://developer.mozilla.org/en/XULRunner ), but I don't think that's been ported to iOS yet...

The other two I mentioned previously are:

http://www.appcelerator.com/platform/titanium-studio

and

http://radicalbreeze.com/

And, of course, Python+QT got mentioned repeatedly.

Hope this helps!

m@

[Simon Haynes]

Matthew Rasnake wrote:

> Just spent more time than I should looking around, and found a few
> interesting things...
>

I had a look too, and it seems there are pros and cons to having separate versions and trying to maintain one codebase which can be cross-compiled for everything.

I like the look of wxWidgets, but I definitely wouldn't like to write the entire yWriter codebase in C++. Say what you like about VB, but string handling is a doddle, and that goes for C# as well.

[Michael Mefford]

For my two cents, and not really to plug a particular language...what about Java?  It's similar in style to C# and has pretty good string handling.  Or, if you're looking to really change things up, there's always Perl or Python.  In fact, my favorite 3D modeler is written in Python (Blender 3D).  All three of these are cross-platform on the desktop OSs and on Android (I think).  The problem is iOS (leave it to Apple).  I believe the only language that really works with it is Objective-C.

 

 

Michael.

 

[Dain Unicorn]

I'd chip in on it... Having recently taken the Mac plunge myself (vista cured me of my begrudged use of Windows -- I still miss DESQView). Either that or finally gotten to the point in my life I can afford real tools and not hobbled together scraps.

Using yWriter via Wine or Crossover is functional but annoying, as the text windows clip the first dozen pixels or so on the left margin.

Dain

Sent from my iPhone

[Josh Nesbitt]

I would jump on that Kickstarter project in a heartbeat. I'd love to have a cross-platform system, especially an iPad version. The other "Holy Grail" feature for me would be automatic syncing via dropbox or something similar, so all projects could be kept up to date on every platform/device.

I'll offer my services as a tester, or in any other manner that I can be useful.

I'll be watching this thread with bated breath and crossed fingers...

[Michael Mefford]

There's this for Basic on Android http://www.basic4ppc.com/.

 

I'm thinking it will be difficult to find that 'one size fits all' solution.  Simon, it may be best to spend your time on one yWriter for Windows/Linux/Mac and then oversee (control) forked projects for both iOS and Android.  It's not ideal, but...

 

 

Michael.

 

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

To view this discussion on the web visit https://groups.google.com/d/msg/ywriter/-/ZYDSln2VK8sJ.

[Josh]

The other idea I have kicked around (I know virtually nothing about coding, so I don't even truly know how feasible this would be) is using HTML5 and its ilk to make a browser based version.

I may be totally out in left field on that one, but I figured I'd toss it out there in case there were some merit to it.

       ___       ___       ___       ___    
      /\  \     /\  \     /\  \     /\__\    
      \:\  \   /::\  \   /::\  \   /:/  /    
       \:\  \ /:/\:\  \ /:/\ \  \ /:/__/     
 __    /::\  \:/  \:\  \\:\~\ \  \::\  \ ___ 
/\ \  /:/\:\__\__/ \:\__\\:\ \ \__\\:\  /\__\
\:\ \/:/  \/__/  \ /:/  / \:\ \/__/_\:\/:/  / 
 \:\/:/  /   \:\  /:/  /:\ \:\__\    \::/  / 
  \::/  /     \:\/:/  / \:\/:/  /    /:/  /  
   \/__/       \::/  /   \::/  /    /:/  /
                \/__/     \/__/     \/__/  

[Matthew Rasnake]

The more I've thought about it, the more I think you should seriously consider Appcelerator Titanium. 6Wunderkinder uses it for their Wunderlist app(s) ( http://www.wunderlist.com/ ), which are great pieces of software, and pretty to boot.

[Janna Willard]

My husband suggested WX Widgets, which apparently has a .net. He says you can write the programs in it (I don't know what languages it works with) and then compile for different OSes, and it applies a GUI based on that OS. So your Mac version looks like a Mac program and your Windows version looks like a Windows program, etc. You can also use it to compile for iDevices, so the iPad thing would hopefully be a good thing.

I, of course, know very little about programming, but hubby currently works in software development. (I basically know enough to use terms correctly most of the time and to sound like I know what I'm talking about; he actually DOES know what he's talking about.)

Anyway, if this WX Widgets thing would work, it sounds like the best option (to me, anyway). Obviously the programmers here will have a better idea about how good it is, and Simon will be able to evaluate it the best! :)

-Janna

--
-Janna

"Nobody realizes that some people expend tremendous energy merely to be normal." Albert Camus
"I want to remake the world; anything less is not worth the trouble." Karen Cushman

[David York]

As a non-programmer (well apart from some history in BBC Basic) I thought I was well qualified to step in here J

 

I started to panic when Simon made two recent statements.  The first was that he was writing Hal Junior books which were relatively easy to structure and write and secondly that he was looking at a rewrite of yWriter to take account of all possible platforms.

The panic was that he would have no incentive to develop the advanced aspects of yWriter that make it uniquely useful for post-first draft editing.  And that he would get diverted from perfecting the program and spend time just rewriting into a multi-platform environment.

 

Then I thought for a while – always dangerous.

 

The yWriter program already goes beyond what Simon needs to use for his own writing – so he continues to respond to legitimate user needs.  And, actually I sympathise with a rounded (or polymath) approach where by an individual achieves maximum fun by working on many projects simultaneously.  Simon is one of life’s productive individuals and always busyness is how he achieves so much. So actually, he will achieve more simple advancement of yWriter by pursuing what might look on first glance to be a diversionary activity.

 

You can almost feel a level of admiration for Simon that starts me asking for an autograph here.

 

So – people (programmers) have been making suggestions on tools to use; what can mere writers do to help?  How about helping Simon design the next yWriter?

 

I want to start that off with 10 strategic thoughts.  Please feel free to weigh in here.

 

1                     some platforms are equivalent in potential although users may have different setups (number of screens, input device etc)

2                     some platforms are naturally restricted and may not be best served by an attempt to have a full yWriter experience implemented (eg can I really expect to do more that originate text on an obsolete Dell PDA or any small modern phone)

3                     the place in the market for yWriter is not just an environment to collect research and bash out a first draft – instead it should have the tools to take that draft to completion

4                     yWriter has recently become a medium to prepare works for e publication – that was a very sensible strategic as well as practical development and should be maintained

5                     yWriter’s backup capabilities – both automated while writing and as executed (eg ftp backup) are already class leading and should remain that way

6                     the degree of user customisation is already good (eg language files) but could be improved for those users who want to tailor what they are working with.  Tags can be more developed.  Edit states could be expanded  from outline, draft etc.  Characters could have more attributes.

7                     viewpoint and other attributes of scenes could be better reported.  The scenes view could be sortable.

8                     things that are variable could be reported so that are more easily tracked (eg times of scenes)

9                     text  could be tagged for collection and reporting (eg speech by character X could be collected for analysis to ensure consistency)

10                 interface with mind mapping (plot/character development) software could be facilitated by publishing a specification to be met for automated input of the output of other programs (eg Freemind/Freeplane)

 

Just my 2p worth as ever

 

Regards

 

David

[Henry Boleszny]

I agree with David's second point.  

One of the main problems with smartphones and slates is the keyboard dominating up to 50% of the screen size.  Using the full yWriter program under those constraints will be inefficient.  Some desktop/laptop users have already described problems with sizing windows to fit screens larger than a slate offers.  

With practice, it's possible to write a note, email or tweet on a Samsung Galaxy Tab or similar device.  However, there's no way that I can write 3,000 words of a novel in yWriter if it was ported for use on something that size.  I 'duck around' and check information stored in different yWriter tabs too frequently as characters insist on deviating from my well-designed and carefully thought-out plot.  

However, some means of editing an RTF file on an Android-powered slate would be invaluable.  One of the biggest problems at the moment for Android users is the lack of a good RTF editor.  However, that is a separate issue and could best be addressed by an app rather than a full program 'port.  

Just my $2.00 (allowing for inflation south of the equator)

Henry 

---

From: ma...@davidyork.co.uk
To: ywr...@googlegroups.com
Subject: RE: [yWriter] Kickstarter/yWriter Mac/iPad
Date: Thu, 5 Jul 2012 22:22:32 +0100

[Simon Haynes]

At the moment my thoughts are running along these lines:

I have too much work (years) invested in the current yWriter5 source tree to toss it all away and start again in another language. yWriters 1-4 were all written in Visual Basic 6 over a decade or so, and then I spent around two years converting this code to dotnet for Vista/Win 7 (hence yWriter5)

Before I started the huge conversion job to dotnet I looked around at various technologies, but MS Visual Studio was the only sane choice. I still stand by that choice, but it would be nice to offer a mac version. Not to compete with Scrivener, but for people who have decided to switch to Mac and would like to use yWriter with their old (and maybe current) projects.

With that in mind, this would appear to be the best approach:

1) Get a macbook pro and XCode, and use that to develop a Mac OSX version of yWriter

To start with, the mac version would have to load a yW5 project, display chapters and scenes, and allow the user to edit them. All extra features disabled, to be added at a later date.

2) Develop a cut-down UI version for the iPad, hopefully using the same source tree.


On the Android & Linux side:

1) Research whether mono will actually run on Android
2) Wait for mono to catch up.

I know, I know. At the moment the best solution for yWriter-on-linux (not Android) is to run a version of Windows in a VM. After that, it appears Wine with Microsoft Dotnet 2.0 installed is the go. Mono is a distant third.

This means I can't compile yWriter against dotnet 4.0, and have to stick with 2.0

As for Windows 8 and the tablet touch screen interface ... I'll wait a year or so to see how that pans out. Visual Studio 2011 is probably the answer to that one.

[McPop]

This thinking is contagious, look out below!

It seems to me that there are a few programmers around on this list.  And it seems that we all love yWriter to bits (no pun intended). Perhaps we could be leveraged in a real and practical way.

One left-field option would be to make yWriter6 open-source.  Simon is a vast repository of knowledge for yWriter and I'm sure all here would respect him as a sage and benevolent dictator for life if such an enterprise was undertaken.

I would envision a high-productivity and cross-platform language as the foundation.  Python seems to be VERY popular among open-source projects (and for good reason) and has bindings for all sorts of frameworks, UI toolkits and IDE support.

I would also envision yWriter to be capable of having plugins/extensions capabilities.  This way we can have a simple and functional yWriter core, which I believe is Simon's current mindset for deciding what comprises yWriter5, and allow dedicated individuals to extend the functionality of yWriter to do the more esoteric things users may want.  Creating a graphical program using a plugin architecture is a very neat,  easy and elegant way to go.  yWriter will essentially be some bootstrap code that loads the "core" or "base" plugin from which the rest of the plugins are plugged into. I think this is how Firefox and Eclipse (and others) do it.

With some smart MVC design patterns, a tablet UI could be produced, perhaps "down the track" as a plugin that is included in the tablet build version. With a plugin architecture it should be straighforward to include/remove features from various incarnations of yWriter depending on the target platform (e.g. dis-include the desktop interface plugins and include the tablet UI plugins) . 

An open-source yWriter is definitely something I would get on board with and contribute time and energy to.

Or, while throwing around nuggets of crazy, HTML5!

Cheers,

A.

[Andrew Roth]

I am a user, not a programmer, a writer of fiction, not of code.  I have used a PC/Vista platform for the past two years with zero issues.  I am contemplating a switch to MAC, but only if yWriter can come along: if not, I am content to continue with PC.

 

My background is in reconstructive surgery; there is an aphorism that is spoken out loud during difficult cases in the operating room:  "The enemy of good is better."  In our world this means that if you try to overgild the lily, you kill it.

 

So while it is a nice idea I would ask Simon to please not divert his energies from the absolutely outstanding support he affords all of us at present just to chase the chimera of more global functionality and usage.

 

Thank you.

Andrew Roth

 

 

 

On Sunday, July 1, 2012 2:21:29 AM UTC-4, Spacejock wrote:

[Dick Keaton]

Andrew, first of all let me compliment you on your use of the word
'chimera'. I don't believe I've seen it used in this discussion group
before, and I can't imagine a circumstance where it would be more
appropriate. I'd also like to go on record as agreeing with you 'in
totum', and hoping that Simon hears your plea.

I have been a yWriter user for several years and I confess I am
sometimes at odds with the members of this user community who seem to
want more and more gadgetry and esoteric customization, no matter what
Simon has already provided. I liken it to a recipient of a negotiable
'life-changing' fortune who isn't quite satisfied because the money
isn't in his or her preferred currency.

One more thing: Permission to you use your aphorism "The enemy of good
is better." It is a guiding principle all writers should take to heart
- lest we overgild the lily.

Thanks for your participation in this forum.

Dick Keaton

> > Hal Spacejock sci-fi comedyhttp://www.spacejock.com.au/Hal1.html

[Ivory John]

Andrew,
I personally use a Windows based platform, but if I were to consider another device, I would install vmware player and continue using yWriter in a trouble free Windows environment where I could focus on writing with my creative side instead of hassling with technical difficulties that continually waken my other side.

I currently use vmware to run xp under windows 7.  It certainly is not necessary, but it allows me to have a 32bit os to connect to work which seems to appease the techies when something goes wrong.  The virtual environment on my machine is plenty fast enough to play streaming high def videos which is more than fast enough for yWriter.

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

To view this discussion on the web visit https://groups.google.com/d/msg/ywriter/-/EUm3RD7qucoJ.

[sofaspu...@gmail.com]

I'm a programmer myself, and while I'm at odds with some of the
viewpoints expressed in this thread -- I personally think that more
compatibility, more platforms, is an unequivocal good, and I applaud
Simon for reaching for it -- I would firmly suggest *not* going
open-source.

Open-source software is a good thing, it really is. But it is not
automatically the best option for a project. And in this case, I'd
say it isn't.

Going open-source always, always, always involves more work, not less.
Someone has to oversee changes. Someone has to code-review to make
sure merges don't bork something else. Someone has to, essentially,
herd cats.

In addition, urging someone to go open-source is basically a lot like
saying "Hey, you made this $NIFTYTHING, you should give it away for
free and let everyone and their monkey's uncle criticize your work on
it." I realize that's probably not the intent, but it comes across
that way.

I personally don't want to open that box. If Simon chooses to, his
perogative, but I don't think it's a good fit for yWriter at this
time.

--B.

[Carl Maniglia]

The main issue with Open Source is that so very often the development time time slows to a crawl and begin to suffer from feature creep and then bloat. The exceptions tend to be projects that are heavily sponsored by commercial concerns who want to tap into the fund of free programming talent. the projects that aren't properly funded are more likely to die because those who initially were so enthusiastic, fall by the wayside because of other commitments or lose interest because the project isn't going their way, etc.

I'm not a detractor of Open source projects - far from it, but Source Forge has more dead in the water projects sitting on it's servers than healthy live ones and the ones that are still live are notable for their success. Unless Simon wants to hand over yWriter to a committee and leave them to get on with it then I suggest he is far better leaving yWriter as proprietary software and be able to control its development. I'm afraid that in many of the forums for applications developed by a single programmer, without exception there is always a group of individuals constantly pushing for the developer to hand over their work to an open source project.

Of course, there's nothing to stop the supporters of open source to start their own Writer's toolkit project. You never know it could end up being the next big thing for writers and beat yWriter, Writers Cafe and Scrivener, etc. at their own games :)

WXWidgets was developed by the same programmer who wrote a competing application to yWriter - Writer's Cafe. It's available for Windows, MAC, varios Linux Distros, FreeBSD & as a portable app. It's not free or open source though. this suggests that WXSidgets is a flexible platform for programming for multiple OS's.

Regards

Carl

[Simon Haynes]

> **

I've posted about Open Source before now, and it's not something which would work with my apps. I can't find my canned response (it's probably on this group somewhere), but basically I'm a hobby programmer and also a perfectionist control freak (in a nice way), and as with my novels I like to be responsible for everything under the label. Right now I know the program back to front, but if bits and pieces were being modified by other people I wouldn't recognise the code and it would take me ages to fix it.

I've just installed monodevelop, gtk sharp and wxWidgets with the dotnet bindings. It's possible I can put my efforts into writing a form converter (vb to wxWidgets) and use my existing VB source code recompiled under Mono.

[Simon Haynes]

I'm just experimenting with gtk+ and vb.net. It might be the answer, and it should be cross-platform using mono too. (Mono is compatible with dotnet 2.0, it's the windows forms which cause issues.)

Regards
Simon Haynes
--
Need help with yWriter?
Check the left hand menu: http://sites.google.com/site/ywritersj/
(Quickstart, getting started, FAQ, user manual, comprehensive help)

Simon Haynes, author and programmer: http://www.spacejock.com
Hal Spacejock sci-fi comedy http://www.spacejock.com.au/Hal1.html
Hal Junior sci-fi for kids http://www.spacejock.com.au/HalJunior.html

[Simon Haynes]

I've just stuck a very small test program up (proof of concept.)

http://www.spacejock.com/test/VBGTK.zip

This needs Mono 2.10 (don't know whether earlier versions will work). This is available for mac, windows and linux:

http://www.go-mono.com/mono-downloads/download.html

(On linux I'd use the package manager to install mono)

After that, just unpack the Zip somewhere and run the exe. It doesn't do much - just a small window with a checkbox and a label.

I've tried it on Windows and Ubuntu 12, but I'm just interested whether it works on Mac as well.

I should have a little more time for programming now I've released Hal Spacejock book five... see below.

Regards
Simon Haynes
--
Hal Spacejock book 5 released today ... http://www.spacejock.com.au/Hal5.html

[Dain Unicorn]

Simon, I'll grab it and play with it over lunch and let you know.

Dain

Sent from my iPhone

[Simon Haynes]

Dain Unicorn wrote:

> Simon, I'll grab it and play with it over lunch and let you know.
>
> Dain
>

I just found out GTK# doesn't have an RTF control.

That's not a show-stopped but it's going to make things tricky. It means I'll have to write my own.

My plan is to convert a few simple apps first - e.g. my new Kindle KDP sales analyser, which is a bunch of code and a relatively simple main form.

[Dain Unicorn]

After some wrangling (Crossover tried to install it repeatedly until I
finally got Mono to take a crack at it) I got what looks like a pop-up
window that has a checked checkbox, a informational dialog box, other
text and a button to click to quit.

Was that what was susposed to be seen or did I miss something?

Dain

[Dain Unicorn]

PNG Screenshot attached

[Simon Haynes]

Dain Unicorn wrote:

> PNG Screenshot attached
>

Perfect, thanks.

Regards
Simon Haynes

[Simon Haynes]

Dain Unicorn wrote:

> After some wrangling (Crossover tried to install it repeatedly until I
> finally got Mono to take a crack at it) I got what looks like a pop-up
> window that has a checked checkbox, a informational dialog box, other
> text and a button to click to quit.
>
> Was that what was susposed to be seen or did I miss something?
>
> Dain
>

No, that's it. Just trying to display a form with a few controls on. If that didn't work there wasn't much point going any further.

Thanks for trying it out.

The important thing is that this would allow me to keep all my source code and 'only' replace everything to do with the user interface. I believe I can write a program which will take a lot of the manual work out of this, but it's not going to work on something as big as yWriter without being almost as big in itself.

I can still use it to convert a lot of my simpler programs first.

Regards
Simon Haynes

[Michael Mefford]

Simon,

If it matters, your little test works on my Fedora 17 install using mono 2.10.8, which really shouldn't be much of a surprise, but it did work.  So, what's the thought...use mono as the back end and GTK for the gui?

Michael.

Regards
Simon Haynes

[Simon Haynes]

Michael Mefford wrote:

> Simon,
>
> If it matters, your little test works on my Fedora 17 install using mono
> 2.10.8, which really shouldn't be much of a surprise, but it did work. So,
> what's the thought...use mono as the back end and GTK for the gui?
>
>
> Michael.
>

Yes, that's the plan. (Vb.net and mono are the same thing, as long as I don't use winforms. As a bonus, mono 2.10 supports dotnet 4.0 so I can move yWriter6 to Visual Studio 2010.)

I've just been experimenting with my new Amazon KDP sales analyser program. I've set up a conditional compile for GTK, and when I build the project it avoids Winforms and uses GTK instead. It doesn't do anything special yet - just a main window, a menu bar and file/open, but it does work with the underlying vb.net code.

I'm about to play with listviews in GTK.

The benefit is that I'll 'only' need to re-do the UI for all my programs, and the code underneath won't need to be changed (much)

I'm still undecided whether to try and write a converter from Winforms or create my own GTK UI designer and re-do them from scratch.

Another option would be to create my own class library with dotnet-compatible wrappers for the GTK code. E.g. the file selector box acts in a similar way in both, but the method of accessing it is completely different. If I wrote my own wrapper I could use the same filesel calls interchangeably. I guess that means rewriting and extending Spacejock.dll so that all the winforms code conditionally compiles to GTK if the build configuration requires it.

Either way, I'll need to convert some of my smaller progs first to get the feel for it.

And on the plus side ... no Kickstarter or Mac needed ;-)

[Tristan Bendixen]

You'll most likely still need a Mac if you wish to port yWriter to iOS. But as others pointed out, it wouldn't be practical to have a full yWriter on a mobile device.

I have been thinking about things I could do with yWriter on Android (phones and tablets alike), but it would likely end up being something that caters to my needs specifically. But isn't that how yWriter started out?

I guess my needs differ from those of the standard yWriter user, since I never format the text while in yWriter. I use a Markdown-like syntax instead, and then I format after exporting. This works primarily because I write short stories, but if I were to write a novel, then I would likely write a script that would convert the markdown for me, using one of the many parsers available for this, to a format I can use, be it LaTeX or something similar.

- Tristan Bendixen

[Simon Haynes]

Simon Haynes wrote:

> Another option would be to create my own class library with dotnet-compatible wrappers for the GTK code. E.g. the file selector box acts in a similar way in both, but the method of accessing it is completely different. If I wrote my own wrapper I could use the same filesel calls interchangeably. I guess that means rewriting and extending Spacejock.dll so that all the winforms code conditionally compiles to GTK if the build configuration requires it.
>

Okay, just had a go at that. I added a GTKMode condition compilation variable, and under regular compiling my file selection dialog code uses the Windows control, while compiling for GTK uses the built-in GTK file selection dialog.

If I do the same for every winforms-using function in my shared library, converting progs to use GTK will be a little easier.

[Simon Haynes]

I include TEX and HTML directly in my scenes, so I can generate print and ebook versions from the same project. That's the reason for all the updates and changes to yWriter exporting over the past 12 months.

I think my first goal has to be yWriter6 using GTK, and then a kickstarter for cutdown android and iPad versions. The most important thing on portables would be to load and save the yW5 project transparently - the exact features on offer aren't relevant. (For example, do you need import from RTF on a portable?

One thing I may have to do is move away from RTF and use HTML or XML instead for the scene content. That would make life a lot easier when it came to editing on portable devices. Word processors which export to RTF generally have HTML export as well.

[Tristan Bendixen]

On Mon, Jul 9, 2012 at 3:50 PM, Simon Haynes <spac...@gmail.com> wrote:

I include TEX and HTML directly in my scenes, so I can generate print and ebook versions from the same project. That's the reason for all the updates and changes to yWriter exporting over the past 12 months.

I think my first goal has to be yWriter6 using GTK, and then a kickstarter for cutdown android and iPad versions.  The most important thing on portables would be to load and save the yW5 project transparently - the exact features on offer aren't relevant. (For example, do you need import from RTF on a portable?

One thing I may have to do is move away from RTF and use HTML or XML instead for the scene content. That would make life a lot easier when it came to editing on portable devices. Word processors which export to RTF generally have HTML export as well.

In my current plans (still only in the planning phase, after all), I've been pondering how to best handle the cases of TEX and HTML, but as I don't currently use those, that doesn't matter all that much. But they also wouldn't be a problem, actually, because my app (along with the attached software) would be exporting/importing back and forth in yWriter, storing text as-is in RTF files accordingly.

I'm not sure if I'm explaining it as well as I perhaps should, but basically I'm thinking it'll be something like this:

 - Project is exported through the application (this can perhaps happen automatically, though that will come with a warning never to edit it on two devices at once).

 - The Android device has access to the information somehow. I haven't yet decided how they should communicate.

 - Changes on the phone will automatically be sent back to the server whenever possible.

 - These should then be saved in the yWriter project.

As you can probably tell, it's still in its rough planning phase, and there are issues I haven't quite figured out how to properly safeguard against.

I once considered asking you, Simon, if it would be plausible to have an option in yWriter to use regular text files, and then defaulting to RTF. But I decided against it, as it would likely require quite a few changes to the inner workings of yWriter.

Using XML sounds like a really good plan, although I'm aware that it's probably quite far off before it's implemented. ;)

- Tristan Bendixen

[Michael Mefford]

Simon,

 

XML is a good idea.  RTF, although functional, is showing its age.  I just think XML is more portable and younger writers (who also know computers) will understand it better than RTF, if they chose to customize their files for publication.

 

 

Michael.

 

--

[belphebe]

On Mon, Jul 9, 2012 at 6:50 AM, Simon Haynes <spac...@gmail.com> wrote:

One thing I may have to do is move away from RTF and use HTML or XML instead for the scene content.

Are you contemplating this for yWriter everywhere or just the Mac/mobile versions?  If you do move away from RTF in yWriter, will we still be able to use RTF in an external editor, or could we still import RTF files?

I alternate between using yWriter and RoughDraft for writing my stories, storing the files in RTF format.  I'd hate to lose that ability. Oh sure, I could probably adapt, if I had to.  I just don't want to!  ;-)

Inez

[Matthew Rasnake]

I would again throw out the idea of a plain-text markup syntax like (Multi-)Markdown, which has gained wide acceptance, and some noteworthy proponents.

The benefit is that your fundamental file unit would be editable in any text editor (not just RTF editors, which makes editing yWriter files on iOS such a nuisance now), and would avoid all the cruftiness of a structural markup like XML.

For this crowd, the most notable Markdown supporting app is probably Scrivener, though many "note-taking" apps, especially on the Mac boast MD as a top-tier feature.

There are other such syntaxes available, but I am most familiar with MD, and it seems to have the broadest user base.

Sent from my iPhone

[Simon Haynes]

Whatever I use it has to be broadly compatible and also some kind of standard. And whatever I use internally, for scene files, there will need to be an RTF or HTML exporter so the finished novel and/or proofing chapters can be loaded into a word processor.

As I mentioned, I'm leaning towards HTML but that can be an issue with Unicode.

Regards
Simon Haynes
--

Simon Haynes, author and programmer: http://www.spacejock.com
Hal Spacejock sci-fi comedy http://www.spacejock.com.au/Hal1.html
Hal Junior sci-fi for kids http://www.spacejock.com.au/HalJunior.html

Michelle Norton wrote:

> I'd add my nay to this. At least the markup needs to be easily
> searched and replaced for manuscript formating for submission like in
> previous versions of ywriter that did not support rtf.

> Michelle
> Writer / Web Designer
> http://michellejnorton.com
> http://denverfictionwriters.com
> http://about.me/michellejnorton

[Matthew Rasnake]

The beauty of something like Markdown is the ability to export (much like yWriter currently does using Simon's special/custom handling for inline TeX and HTML) to all kinds of different formats. The benefit is that Simon could tap into existing tools, instead of having to define his own syntax and write all custom code to handle the processing/export step. MultiMarkdown exports/converts directly to HTML/XHTML, LaTeX, OpenDocument, and OPML using the main multimarkdown tool. 

On Mon, Jul 9, 2012 at 9:41 PM, Michelle Norton <tirj...@gmail.com> wrote:

I'd add my nay to this. At least the markup needs to be easily
searched and replaced for manuscript formating for submission like in
previous versions of ywriter that did not support rtf.

On Mon, Jul 9, 2012 at 7:36 PM, Matthew Rasnake <ma...@coffeemonk.com> wrote:

Michelle
Writer / Web Designer
http://michellejnorton.com
http://denverfictionwriters.com
http://about.me/michellejnorton

[Michelle Norton]

I'd add my nay to this. At least the markup needs to be easily
searched and replaced for manuscript formating for submission like in
previous versions of ywriter that did not support rtf.

On Mon, Jul 9, 2012 at 7:36 PM, Matthew Rasnake <ma...@coffeemonk.com> wrote:

[Simon Haynes]

Matthew Rasnake wrote:

> The beauty of something like Markdown is the ability to export (much like
> yWriter currently does using Simon's special/custom handling for inline TeX
> and HTML) to all kinds of different formats. The benefit is that Simon
> could tap into existing tools, instead of having to define his own syntax
> and write all custom code to handle the processing/export step.
> MultiMarkdown exports/converts directly to HTML/XHTML, LaTeX, OpenDocument,
> and OPML using the main multimarkdown tool.
>

I took a look at the code and it's pretty much what I used to use in text editors when I was away from the PC. Asterisks for bold, underscores for italics, etc. It's trivial to implement, although the trick is to display the correctly formatted text in the editor window. (The GTK Pango library looks like it'll do that.)

I'd just allow the user to export yWriter to MMD and they could pick a tool for additional conversions. (That's what I do with ebooks - export to a suitable HTML file.) I'm not going to include other people's code or applications with yWriter because there's no way I'm falling foul of GPL or licensing requirements.

[Simon Haynes]

In case anyone hasn't seen raw RTF code before, this is what I have to contend with;

{\rtf1\ansi\ansicpg1252\deff0{\fonttbl{\f0\froman\fprq2\fcharset0 Palatino;}{\f1\fmodern\fcharset0 Palatino;}{\f2\fswiss\fcharset0 Palatino;}}
{\colortbl ;\red0\green0\blue0;}
\viewkind4\uc1\pard\nowidctlpar\fi192\li72\cf1\lang3081\kerning1\f0\fs24 Clunk dropped the last chess piece into the small wooden box and looked around the flight deck. It didn't look particularly clean, despite his best efforts with a mop, but compared to its previous state it was as sterile as a hospital ward.\f1 \f0 Satisfied, he approached the console, and a moment's hesitation he sat in the pilot's chair. "Navcom, do you have a business directory?"\f2\par
\f1 "\f0 Affirmative."\f2\par
\f1 "\f0 Run a search, please. I'd like all your data on a company called Incubots."\f2\par

It's not exactly reader-friendly, and it's a nightmare to parse and work with. Hence the issues with font formatting 'sticking' sometimes (amongst other issues.)

Regards
Simon Haynes
--
Need help with yWriter?
Check the left hand menu: http://sites.google.com/site/ywritersj/
(Quickstart, getting started, FAQ, user manual, comprehensive help)

Simon Haynes, author and programmer: http://www.spacejock.com
Hal Spacejock sci-fi comedy http://www.spacejock.com.au/Hal1.html
Hal Junior sci-fi for kids http://www.spacejock.com.au/HalJunior.html

[Matthew Rasnake]

On Mon, Jul 9, 2012 at 10:23 PM, Simon Haynes <spac...@gmail.com> wrote:

I'd just allow the user to export yWriter to MMD and they could pick a tool for additional conversions. (That's what I do with ebooks - export to a suitable HTML file.)  I'm not going to include other people's code or applications with yWriter because there's no way I'm falling foul of GPL or licensing requirements.

Markdown is under a BSD-style license (no restrictions, or "code-release" requriements, you'd just have to include the original copyright notice), while Multimarkdown is under them more restrictive GPL.

Totally understandable, though perhaps you could include hooks to use markdown/multimarkdown for export/conversion if the user already has them installed (i.e. you don't include it in your packages, but nevertheless call it directly if possible.)

I really don't mean to keep pushing this, it just seems like now is the single best time in yWriter's life-cycle to make recommendations about fundamental aspects of the program...

-- m@

[Simon Haynes]

Matthew Rasnake wrote:

> On Mon, Jul 9, 2012 at 10:23 PM, Simon Haynes <spac...@gmail.com> wrote:
>
> > I'd just allow the user to export yWriter to MMD and they could pick a
> > tool for additional conversions. (That's what I do with ebooks - export to
> > a suitable HTML file.) I'm not going to include other people's code or
> > applications with yWriter because there's no way I'm falling foul of GPL or
> > licensing requirements.
>
>
> Markdown is under a BSD-style license (no restrictions, or "code-release"
> requriements, you'd just have to include the original copyright notice),
> while Multimarkdown is under them more restrictive GPL.
>
> Totally understandable, though perhaps you could include hooks to use
> markdown/multimarkdown for export/conversion if the user already has them
> installed (i.e. you don't include it in your packages, but nevertheless
> call it directly if possible.)
>

Calibre has a problem with being called directly, I think, which is why I leave the final conversion to the user.
I could create Dos batch files at the same time the file is exported, but that won't help Mac and Linux users.

> I really don't mean to keep pushing this, it just seems like now is the
> single best time in yWriter's life-cycle to make recommendations about
> fundamental aspects of the program...
>
> -- m@

No problem at all - it costs me nothing to seek opinions and evaluate suggestions, and there's a lot of accumulated knowledge amongst members of this group.

Off-hand, do you know whether MMD supports fonts (typeface, style and size?)

[Matthew Rasnake]

On Mon, Jul 9, 2012 at 10:55 PM, Simon Haynes <spac...@gmail.com> wrote:

Off-hand, do you know whether MMD supports fonts (typeface, style and size?)

Off-hand, no.

Multimarkdown's LaTeX output, however, relies on (as I understand it, anyway) XSLT to convert (internally) the normal XHTML output to LaTeX, and the LaTeX output then relies on the normal "templates" (like memoir, etc.) to give structure and appearance settings. (don't remember if they're called templates, but I imagine you understand what I'm saying).

To my knowledge, the HTML/XHTML output from markdown uses default styles (i.e. NO fonts). I *think* you may be able to specify a stylesheet in MultiMarkdown metadata, which would get linked in the HTML output, but I'm not 100% certain of that, and could be totally making it up.)

I haven't done a lot of the advanced (Multi)Markdown stuff, and the only ebook i've created with it I went straight to HTML (which I styled "by hand"), then used Calibre's ebook-convert on the command-line to get from HTML -> ePub.

[Michael Mefford]

So...maybe I'm wrong in suggesting this, but...maybe yWriter shouldn't use any formatting.  Maybe it should use just plain text.  Now, before I'm tied to a post and lit aflame, here's my reasoning:

 

First, it would be easiest to implement (a simple text editor).  Second, an author needs to focus on the content of the story first, formatting comes later during the publishing phase (typesetting is not a yWriter function).

 

Don't get me wrong, I like to write using formattable text.  As many authors know, the ability to bold, italicize, etc is crucial to emphasize certain things within a story.  Yet, we shouldn't get so hung up on formatting.  At its core the editor in yWriter is just and editor, and the fact that we can format text at all is a bonus.

 

Do we want formattable text: yes.  Do we care how it is handled on the back end: not really.  So, the solution is..whatever Simon thinks is best to use considering his time.  As for exporting to other formats, that's what plugins are for.

 

 

Michael.

 

--

[Simon Haynes]

Michael Mefford wrote:

> So...maybe I'm wrong in suggesting this, but...maybe yWriter shouldn't use
> any formatting. Maybe it should use just plain text. Now, before I'm tied
> to a post and lit aflame, here's my reasoning:
>
> First, it would be easiest to implement (a simple text editor). Second, an
> author needs to focus on the content of the story first, formatting comes
> later during the publishing phase (typesetting is not a yWriter function).
>
> Don't get me wrong, I like to write using formattable text. As many
> authors know, the ability to bold, italicize, etc is crucial to emphasize
> certain things within a story. Yet, we shouldn't get so hung up on
> formatting. At its core the editor in yWriter is just and editor, and the
> fact that we can format text at all is a bonus.
>
> Do we want formattable text: yes. Do we care how it is handled on the back
> end: not really. So, the solution is..whatever Simon thinks is best to use
> considering his time. As for exporting to other formats, that's what
> plugins are for.
>
>
> Michael.
>

yWriter was originally designed for writing novels (only), but that's before the rise of ebooks. First I added ebook export, but then I needed to export from the same project to generate Latex (for paperback editions) and RTF (for Smashwords ebooks) That means yWriter has to support all the formatting I might need to generate books. The last 12 months have involved adding all the code to do this. On the surface it's invisible apart from a new option here and there, but each of my 8 novels/paperbacks/ebooks are generated from rather complicated yWriter projects - including footnotes for some, illustrations for others, and a lot of other things I've forgotten. (If anyone were to see how I'm using global variables, project variables, HTM and TEX tags and conditional export they'd probably have a fit.)

So, formatting is essential, but not complicated formatting. I'm happy to leave footnotes etc to the post-processing software as long as I can include the code between relevant tags. (If you're not aware of this feature, you can include Latex code between <TEX and /TEX> tags anywhere in scenes, and the same for HTML code.)

[Michelle Norton]

Urg...i'd vote to keep formatting for tabs, italics, undreline and bold....have you ever searched a 100000 word doc to put formatting in?..it sucks.

[Dave Shaw]

I agree. My process is to write in yWriter, export to rtf, convert to MS Word
.doc, and do font and paragraph formatting to submission standards in the word
processor. What I consider text formatting (italics, bold, underline) is, to
me, part of writing, and properly belongs in yWriter. I don't want to go back
to the days of yWriter3 when that support wasn't there, and I would hate to have
to enter cryptic codes in my text just to set such simple formatting.

I imagine Simon understands this, but I wanted to make it clear to people
offering suggestions that this is a requirement for me and probably a
significant number of 'old school' yWriter users. We're not all messing with
making up our own eBooks using LATex and such - we just need simple, continued
support for getting our work into MS Word format for submission to our agents
and editors, since most of them here in the States still specify .doc files.

Thanks.

Dave Shaw
________________________________
From:Michelle Norton <tirj...@gmail.com>
To:ywr...@googlegroups.com
Sent: Tue, July 10, 2012 12:24:33 PM
Subject: Re: [yWriter] Re: Kickstarter/yWriter Mac/iPad

[Michael Mefford]

Ok, so I wasn't saying yWriter should lose formatting.  Good writing software needs it.  I just wanted to point out that in the writing process, format is secondary to content (not really a software related point) and that as authors we shouldn't really care how yWriter stores our information, just that it is safe, secure, and exportable.  We really shouldn't have to copy and paste into other software or mess with the raw files just to have our finished product (in a perfect world).

 

yWriter needs formatting, we should care what happens inside, and we should be able to export to DOC, RTF, HTML, XML, PDF, LaTex, or whatever...but, export control is an add on (plugin) and for the end user really doesn't control how data is stored.  Simon, use RTF or HTML or XML or whatever.  It should not matter to the author.

 

Of course, as an engineer I might vote for a yWriter with a separate publishing module, something removed from the actual authoring module (yWriter).  Perhaps it could be a whole new product with which yWriter interacts.

 

 

Michael.

 

[Matthew Rasnake]

On Tue, Jul 10, 2012 at 1:36 PM, Michael Mefford <meff...@gmail.com> wrote:

yWriter needs formatting, we should care what happens inside

I think moving away from RTF to some form of human-readable markup language (be it XML, Markdown, or what have you) doesn't necessarily mean that you'd have to enter obscure text-formatting by hand. The way I see it, XML or Markdown is (or can be) a behind-the-scenes thing (like RTF currently is), and for the average/normal user, there'd be zero difference in the day-to-day use of the app. Especially in the use case of the "old school" users mentioned previously, who just want a way to get their novel into a .doc format file. However, for those of use who live simultaneously on several different platforms (I write and edit on Ubuntu, Mac, my wife's iPad, and my iPhone), having a human-readable, simple text markup that we can edit in any of a dozen iOS apps would be a huge boon, and would allow me to "stay within" yWriter, instead of exporting and then re-importing the project.

-- m@

[Dave Shaw]

Understood.  I just wanted to make it clear that I don't want to see what I would consider a step backward in the editor interface.

There is one other group of users that would be affected by moving away from rtf, though.  I don't have any idea how many people routinely use the external editor option for scenes, or how much formatting they do using it.  If anyone is doing 'fancy stuff' this way that the yWriter scene editor doesn't support, that could be a barrier for them moving to a different format, depending, of course, on the capabilities of the new format and such editors as support it.  I don't know how to determine whether this is a significant issue, but I think it should be part of the discussion.

Of course, I think there have been support issues with it in the past, so Simon might be just as happy if it did go away. (grin)

Dave Shaw

---

From: Matthew Rasnake <ma...@coffeemonk.com>
To: ywr...@googlegroups.com
Sent: Tue, July 10, 2012 2:27:43 PM

Subject: Re: [yWriter] Re: Kickstarter/yWriter Mac/iPad

[Matthew Rasnake]

On Tue, Jul 10, 2012 at 3:44 PM, Dave Shaw <dave...@bellsouth.net> wrote:

how many people routinely use the external editor option for scenes

It's a fair point. During the writing of my novel, I relied on the external scene editor functionality since yWriter's scene editor forms were so squirrely under Mono on Linux.

Of course, I also had to try several editors before i found a decent one that supported RTF. ;)

-- m@

[Ivory]

Everything I have exported from yWriter has needed significant cleanup.  I start with removing all embedded codes then go back and re-bold the chapter headings.  This may be due to the age of my projects, and the fact that when I imported them into yWriter, it had issues bringing certain formatting into RTF.  I had written tools to fix the quotes to straight quotes and some of the paragraph inserts and extra font changes added by Word.  I can attest to the difficulty of working directly with RTF text commands.  I doubt that any other text based rules would be without similar problems.

I think I have mostly stopped adding font changes and could probably live without them, but I am writing fiction.  If I were producing tech documents, however, I would be unable to live without bold, italics or underline.  Certainly, a pure text based editor would pair up nicely with the typewriter sound effects  ;)

[Henry Boleszny]

Documents to Go 'allows you to VIEW (emphasis added) Microsoft Word, Excel and Powerpoint files'.  Unless you pay for the full version, you can't edit anything.  

Some might regard me as a cheapskate, but I resent paying to do more than read my own documents.  $14.99 USD mightn't sound like much, but in the world of Android apps, it's a fortune--especially for a pensioner.  

Google Drive provides a 'read only' option for RTF files.  That's unworkable if you want to edit a scene on an android device.  

It's rendition of MS 'native' formats is clunky at best.  I have a critical spreadsheet in MS Excel that I tried to update in Google Drive.  It crashed when I tried to return the file to my PC.  Repeatedly.  Google had corrupted the code during its 'translation' process.  

I know there's been an active debate to make yWriter platform-independent.  Personally, I prefer it AS IT IS, despite the limitations and difficulties of editing away from my PC or laptop.  

It works.  It's reliable.  It's efficient.  It's written by an author for authors.  Simon has done a great job with yWriter since making it available to us.  

Just my point of view, from someone who tested a range of options and keeps coming back to yWriter because its the best option out there.  

Henry

---

Date: Wed, 11 Jul 2012 02:03:20 -0700
From: 2.mark....@gmail.com
To: ywr...@googlegroups.com
Subject: [yWriter] Re: Kickstarter/yWriter Mac/iPad

 

 

 

 

What would make it more portable for me, would be if yWriter could export to online storage, in a format ch000-sc000.rtf. That way, I can work on scenes, in and on pretty much any device. Maybe even add new scenes outside yWriter simply by using the correct file naming format. This could also provide a simple sync/back-up option.

Googler drive with google docs could offer another option, although I'm not sure what format a .gdoc is.

 

I'm looking forward to a possible iPad version/compatibility, as I currently work on scenes using Pages, with the awkward importing and exporting. While the iPad is great for drafting / proofing, as with most mobile devices, I struggle to do any real editing on it.

 

 

 

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

To view this discussion on the web visit https://groups.google.com/d/msg/ywriter/-/BaKlA5EByR4J.

[Ivory John]

I personally don't want my heart and soul in the cloud, but if that is what you want, yWriter will export chapter and scene, and ySync will sync it to another drive/folder which I presume could work with the cloud.

[Peter Barns]

On 12 July 2012 01:14, Ivory John <ivory...@gmail.com> wrote:

I personally don't want my heart and soul in the cloud, but if that is what you want, yWriter will export chapter and scene, and ySync will sync it to another drive/folder which I presume could work with the cloud.

On Jul 11, 2012 10:03 AM, "Mark Edwards" <2.mark....@gmail.com> wrote:

 Why change something that works perfectly fine. Unless of course Simon can produce a piece of software that will write my novel and earn me a fortune. Three Hundred Shade Of Greenbacks perhaps?

 

 

 

What would make it more portable for me, would be if yWriter could export to online storage, in a format ch000-sc000.rtf. That way, I can work on scenes, in and on pretty much any device. Maybe even add new scenes outside yWriter simply by using the correct file naming format. This could also provide a simple sync/back-up option.

Googler drive with google docs could offer another option, although I'm not sure what format a .gdoc is.

 

I'm looking forward to a possible iPad version/compatibility, as I currently work on scenes using Pages, with the awkward importing and exporting. While the iPad is great for drafting / proofing, as with most mobile devices, I struggle to do any real editing on it.

 

 

 

--
You received this message because you are subscribed to the Google Groups "yWriter" group.
To view this discussion on the web visit https://groups.google.com/d/msg/ywriter/-/BaKlA5EByR4J.
To post to this group, send email to ywr...@googlegroups.com.
To unsubscribe from this group, send email to ywriter+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/ywriter?hl=en.

--
You received this message because you are subscribed to the Google Groups "yWriter" group.
To post to this group, send email to ywr...@googlegroups.com.
To unsubscribe from this group, send email to ywriter+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/ywriter?hl=en.

--

Author, poet and versifier
Website: http://www.boddaert.co.uk
Blog: http://www.boddaert.co.uk
Facebook: https://www.facebook.com/BoddaertBooks
Twitter: https://twitter.com/#!/peterbarns
Google+: https://plus.google.com/u/0/116474181837279550921/posts
My ebooks: https://www.smashwords.com/profile/view/boddaert
My treebooks: http://www.lulu.com/spotlight/boddaert

[sofaspu...@gmail.com]

I've explained before on this list my personal process, where I use
Google Docs to edit scenes from time to time outside of yWriter and
synch back later, and I haven't noticed any problem with editing RTF
files in Google.

I'm not saying it's *ideal*, I'm just pointing out it's not read-only.

That said, I'd like to see something other than RTF. I don't have a
good answer as to what, but, I know RTF is only going to cause more
headaches as time goes on. I'd suggest HTML but that'd just be
trading one throwback for another :).

(I guess you could define a default stylesheet and then use markup
tags. Which would at least make it simple to export. But I can think
of all sorts of edge cases where that could get silly. Not
unworkable, but, silly. Hmm.)

--B.

[Chris....@csiro.au]

While I love writing the first draft of anything in yWriter, I use ‘open with external editor’ constantly when editing. Word’s great for picking up all those little typos and misspellings I seem to pepper my writing with, and even the grammar checking stuff helps sometimes (I did say sometimes ;-)  ).

 

I don’t know if the external editor function’s tied in with the RFT file format, but if RTF gets dropped will the function still be available with whatever replaces it? I really do rely on it once I’m happy with a story’s overall structure.

 

Cheers

C

 

From: ywr...@googlegroups.com [mailto:ywr...@googlegroups.com] On Behalf Of Dave Shaw
Sent: Wednesday, 11 July 2012 5:45 AM
To: ywr...@googlegroups.com
Subject: Re: [yWriter] Re: Kickstarter/yWriter Mac/iPad

 

Understood.  I just wanted to make it clear that I don't want to see what I would consider a step backward in the editor interface.

 

There is one other group of users that would be affected by moving away from rtf, though.  I don't have any idea how many people routinely use the external editor option for scenes, or how much formatting they do using it.  If anyone is doing 'fancy stuff' this way that the yWriter scene editor doesn't support, that could be a barrier for them moving to a different format, depending, of course, on the capabilities of the new format and such editors as support it.  I don't know how to determine whether this is a significant issue, but I think it should be part of the discussion.

 

Of course, I think there have been support issues with it in the past, so Simon might be just as happy if it did go away. (grin)

 

Dave Shaw

 

---

From: Matthew Rasnake <ma...@coffeemonk.com>
To: ywr...@googlegroups.com
Sent: Tue, July 10, 2012 2:27:43 PM
Subject: Re: [yWriter] Re: Kickstarter/yWriter Mac/iPad

On Tue, Jul 10, 2012 at 1:36 PM, Michael Mefford <meff...@gmail.com> wrote:

yWriter needs formatting, we should care what happens inside

 

I think moving away from RTF to some form of human-readable markup language (be it XML, Markdown, or what have you) doesn't necessarily mean that you'd have to enter obscure text-formatting by hand. The way I see it, XML or Markdown is (or can be) a behind-the-scenes thing (like RTF currently is), and for the average/normal user, there'd be zero difference in the day-to-day use of the app. Especially in the use case of the "old school" users mentioned previously, who just want a way to get their novel into a .doc format file. However, for those of use who live simultaneously on several different platforms (I write and edit on Ubuntu, Mac, my wife's iPad, and my iPhone), having a human-readable, simple text markup that we can edit in any of a dozen iOS apps would be a huge boon, and would allow me to "stay within" yWriter, instead of exporting and then re-importing the project.

--

[Simon Haynes]

<Chris....@csiro.au> wrote:

> While I love writing the first draft of anything in yWriter, I use 'open with external editor' constantly when editing. Word's great for picking up all those little typos and misspellings I seem to pepper my writing with, and even the grammar checking stuff helps sometimes (I did say sometimes ;-) ).
>
> I don't know if the external editor function's tied in with the RFT file format, but if RTF gets dropped will the function still be available with whatever replaces it? I really do rely on it once I'm happy with a story's overall structure.
>
> Cheers
> C

I've moved away from a cross-platform solution in a new language now.

Mono wasn't up to the task, but wine seems to be the answer for mac & linux. (The guys on the wine bugs web page are very helpful too.)

I also downloaded the mono source code this morning and found the bug in their code which was causing issues with closing dialog boxes. I've given them more detail, including the specific line which is causing problems, so hopefully they'll fix it and users will be able to run yWriter on mono OR wine.