Thank you for this, and please stick around.
Nephele is a valuable member of the development team, but he can be a bit uncompromising. There are many Haikunauts who agree in principle with the No-LLM policy, but would prefer a less confrontational approach to those who think differently.
And I am not sure you do think differently, anyway. I can see no harm in using AI for testing (speaking as a non-developer).
It depends what your arguments against AI are. If it is worries about the code quality, yes, thatās fine. If it is about the ecological or ethical consequences, then a more strict approach makes sense. That is the policy we haĆ¢e chosen on the forum to categorize topics. It is just a forum categorization and itās helhful for people who really care about that. For other people it should make no difference, they can read the forum posts just as well.
Thank you for the encouragement! I think very similar, only slightly differentiated as I face the same issues in my job as Haiku faces here but also see an evidence of possible positives.
And @PulkoMandy: āIf it is about the ecological or ethical consequences..ā I fully agree. Forgot only āSocialā which me thinks are the driver of the ecological and ethical.**
**
Can we now make this post somehow about writing and reading documents again? I would really appreciate it.
There is a topic or 50 of those about LLMsā¦
I was talking about the practical issue. As for the ecological/environmental issue, I personally think that is a matter for individual consciences, and not for Haiku to dictate. The fact is that whether people use AI for Haiku or not is not going to make any material difference whatsoever to the planet.
But perhaps in future, when Haiku attains the popularity it deserves, it will make a difference. We can dream.
Yes, and thatās why we are only trying to put things in the right forum category, so people can easily make that personal choice. That does not dictate anything.
Somehow, some people keep feeling offended that we do that. It only means that, despite using LLMs, they themselve are uncomfortable with it. Otherwise they would have no issue with just being in the correct forum category, right?
As for making a difference or not, maybe not by direct means. But just saying āa world without LLMs is possibleā, and showing the way, seems important to me. Either it works and it ends up making a material difference, or it doesnāt, but at least I will die peacefully, knowing that I did my best to limit the problem, rather than go full-on on it.
@ilfelice Back to input method (IME) subject:
I checked the rudimentary Developing IME Aware Applications | Haiku Project and some input_server code, I do not understand half of the IME handling, while I understand how to use it now.
Also it seems that only Japanese input methods are mature with Chinese being partly there from long time ago. I could not find Hangul/Korean.
What is then possible IMHO:
This leaves me with the āUse what is thereā - that should be a day or two, not a month of work and will keep the engine/executable not depending on too many libs and at fashionable sizes < 20 MB as well.
Maybe Dragān drop can help here too!
Great Work will try at weekend.
EDIT: To choose a Font it wold be great to Just dragān drop the apropirate Font from an App Like Fontboy over to your puretext app.
Just an Ideaā¦
Thanks brunobastardi, text drag and drop is there (on your request - but local to the application not drag to other apps) there are plenty of things to finish before polishing, there is not even a settings screen yet. But I agree, proper Haiku integration should be there at the end.
Please gather all nice-to-have and send here in few weeks or so the whole list (if you have time, have a list and if you tried to use it, as a matter of course), it is much easier to work on several things at once for me than keeping notes during working day or rereading the whole thread, which is now mostly off-topic.
I completely respect your views, and in fact largely share them.
Hi @pamen
I understand now.
I can only talk about Japanese, which is what I use. A couple of observations:
Vertical text is very rare, so I think you can leave it out if it makes things simpler.
Now, at least for Japanese, you donāt need to implement an IME; a mozc port for Haiku exists in the HaikuDepot, and it does all the conversion heavy lifting (dictionaries included).
So, what really needs to happen is for the text view to accept inline input. I may be off, but the recent native Firefox port recently added inline input; maybe there are some hints in there to follow (again, I may be wrong). Perhaps @3dEyes or @KENZ can provide some insight.
Anyway, if you need testing for this, I am very willing to help.
Keep us posted!
Thanks,
I will try without mozc (for reasons outlined before - dependencies and not OS standard, and I do not trust ports too much without checking - been burned several times).
When something is there I will post it and will surely appreciate if you can check it out, my nearest Japanese friend is not using Haiku and lives some 1.5K km away.
Consider me your Japanese friend who uses Haiku (although I am not Japanese). Anyway, no pressure; if you ever get something going, remember that I willing to help.
PS: mozc works well in my experience; I discovered it several years ago, and never had a problem with it in Haiku.
PureWriter opens .rtf files perfect!
There is no other app on Haiku with this accuracy, well done.
Text dragān drop works just fine like any Haiku app should do!
could no wait to test it!
Just great!
Glad to hear that brunobastardi !
Try to open a complex ODT file in MS Word and in PureWriter - Iām curious if you spot the differences; try to open MS Word (docx) in LibreOffice and Pure Writer - Iām also curious if you can find the differences.
To add some salt to the mix and lower expectations in one go:
Differing Pagination / text flow - LibreOffice, Word and PureWriter may differ what they consider a page, unless page breaks are specified by users - this will not change and is the same issue as between Word and LibreOffice.
RTF 1.91 (LibreOffice does not fully support it) does not support many features: Math will be exported (from the app) as plain images, bibliography or any custom index as plain text and so on.
ODT is native to PureWriter but the app is not (and does not aspire to be) LibreOffice - at the top of the post I mention it. No Macros no XForms, some features like editing time or last print will be manually editable, but not functional. Haiku has one user - āUserā so to have the correct author or document tracking reviewer - use document properties.
PureWriter stores in ODT own data (called private data) for features not supported in LibreOffice / OpenOffice - so a resave in LibreOffice may remove that sometimes, depending on the LibreOffice Version.
Iām looking at the Japanese input, maybe by Sunday - it is quite easy in code thanks to Haiku but hard on the UI interaction, especially without knowing the language.
I had not much time to test and try it.
But I am impressed.
Open a .rtf will open in correct Zoom (137%) which is not possible in Calligra Word, or Scribus!
The only thing I miss, the app should open/remember its last size too.
So far so good, I hope some more professionals will join your work and make it even better.
It works, and it works great.
Thank you
And dragān drop is a real, wow from my side.
Hi Pamen,
Just to make this clear, I do quite apreciate this effort. 
I am often quite direct in my communication (but then, If i ask a question or so, it usually is only a question)
Personally, I disagree slightly. I think if the authors views of something is too far removed from what Iād consider sane that reflects on the software aswell, and I would not trust the author any by extension their code. Though this is mostly the case for e.g extremists that also happen to be software developers. So itās not completely divorced from it.
With that said, letās get to some word-processor related questions
What is the ānativeā format of PureWriter? does it have itās own in-memory format or is it dealing with odt elements directly?
I am curious also since Haiku has this mentality of using translators, i.e libraries that transform āsomeā format from the source towards the format the app uses internally. For example PNG gets transformed to a BBitmap for ShowImage and such. So ShowImage does not directly support images.
Perhaps your code would lend itself to this aswell? One Major problem I have with something like libreoffice is that it really is a big monolithic block. So Iām always looking for options to make stuff simpler and more modular (Libreoffice clearly tries this too, but it often fails. For example opening the āformula editorā in Impress opens in a new window, but no live updating in the other window, hard to gauge how the formulat comes outā¦)
(And I consider that having less code in one big block makes it more maintainable, also because one has to properly think of the interfaces)
Anyway, Iām looking forward to checking it out when you put it on codeberg!
Thanks for the comment nephele
ODT is directly written and read, the code for the engine is already on Codeberg since few weeks and being updated in /engine of PureMail repository. Iām messy with projects, so I did not properly structure the folders on my machines - now I have to figure out how to commit the appā¦
The engine can be forked and made into translators (it can be headless by design), but I would advice against it while it is still work in progress.
Translators are used for graphic formats, where one exists, only some like B/W FAX TIFF format needed for PDF is coded (again - files are relatively separated, this can be reused)
Modularity hopefully is given by the premise - engine does documents and allows to instantiate document surface. Although I may have botched some of that assumption by writing new and converting old code too fast.
How far it is usable for translators - not sure, Iām an app writer by profession but I will gladly help to untangle the code, if needed once this project is sort of grown-up and it could be good enough to call it a translator.
And - I fully agree āauthors views of something is too far removedā- end users are the judge and executioner for any piece of software. Devs are horrible at that, myself included. My only advantage is that Iām not educated as math major or programmer, and I build business apps in constant circular and very painful relationship with my customers (from complete computer idiots but knowledgeable people to plain simpletons but with a lot of computer knowledge and even more arrogance).
I do not care about languages, tools but I do care about basics - Input-Processing-Output, what is useful, does what it should and requires minimal corrections (ideally, never happens).
I have a behemoth at work with 6m lines of code and that is very hard to manage but basically impossible to steal - frameworks on top of frameworks under state machines and security watcher libsā¦ Again - simpler is better, but not always.
Have a nice one.
Now Some Japanese writing end-user help needed for IME:
ilfelice Iām not sure if you actually can write Hiragana / Katakana but if you do - would be great if you can answer this, as I have no experience in Haiku IME:
Letās assume you have Mozc on Haiku and switched it into Hiragana mode.
Composing starts, you type a word - maybe ānihongoā in romaji (I know probably 5 Japanese words, so I hope using āJapaneseā in Japanese is not offensive to anyone).
You should see an expanding list , ę„ę¬čŖ should be the underlined match.
Then a space would confirm the choice and Enter sets the ę„ę¬čŖ into the editor.
A āCommandā / āLeft Windows keyā cancels composing, the same happens if you switch in Mozc (or BeCJK or whatever you have installed) back to āRomanā i.e. Latin(-ish - could be Serbian Cyrrilic or Greek - whatever your current keymap / keymap switcher shows).
Is that sequence of keystrokes correct or did I miss something?
Edit: I forgot language marks - each selection / paragraph is marked as specific language, this will also imply adding an input method mark , so externally - select a word or paragraph and you can mark it as Japanese / Korean/Chinese input method and internally this must translate to ālangā tag for consistency and possible spell check (I cannot find any jp-JP spell checker for hunspell though)
I find this piece of software rather impressive.
(+) Iāve never been able to open an ODT or ODS file so quicly in any other OS. It is not exaggeration to say the application starts just as fast as StyledEdit. It is also perfectly responsive and stable during use.
(+) It is surprisingly feature-rich for a 6 MB āsingle-fileā application. Good use of system libraries.
(+) I really love that the ruler is visible also for spreadsheets. A feature I miss from LibreOffice.
(+) Itās hard to say specific good things about it when it generally just works as should.
The few cons I could mention:
(-) I noticed that the package sets the default association of plain text files to PureWriter. It is not particularly annoying considering how quick the application is. But I still think it shouldnāt do that. StyledEdit is a perfect default for basic text files, imo.
(-) If we highlight a word so the highlight starts at the first letter of the word, it will be expanded to include the whitespace before and the highlight will start at the end of the previous word instead.
(-) Sometimes if we check strikethrough or overline in character formatting, the app gets confused and doesnāt allow us to set the line style or colour for the underline on the same text.
(-) I donāt expect the writer to fully support spreadsheet documents, it is not a spreadsheet app after all, and itās awesome in itself that it even opens ODS files. It would be nice though if it didnāt automatically print grid lines for cells that donāt actually have an edge style set. Or perhaps add the option on the Page Style window, if possible. Along with the option to not automatically include the sheetās name in the print.
(-) The tabs on Page Style window donāt fully fit in the window.
Features I would like to see:
(*) I would love support for opentype features included. (Ligatures, stylistic sets, etc.) I miss this dearly. Since the app already uses the freetype library directly, do you think it would be hard to implement that?