File Edit menu
Sold, well it would be if it wasn't free
The Document Foundation has made some tweaks to improve file loading and save times in its word processor and spreadsheet programs in the latest version of LibreOffice, 6.3. The open-source office suite for Windows, macOS and Linux – which consists of a word processor, spreadsheet, presentation graphics, diagramming tool and …
yeah I had to deal with a "UX" designer recently. He took 3 times longer than he should have to develop a FRACTION of what needed to be "DONE" by "certain time frame". I ended up taking over [being responsible for integration] to the point I just asked him to make 3 UI screens [embedded Web UI]. When he got those to me, I cloned them for the rest of the interface, and and the whole thing done in a few hours. during that time he apparently PANICKED and even started reverting my git commits. Finally I just gave up on him completely and asked him to create a single screen I was having trouble cloning from his existing code [which he did]. Lots of slack messages back/forth and him whining and complaining and "thanks for taking work away from me" etc. Well he did THAT on his own, through his own efforts.
And the worst part - most of the "work" was 3rd party libraries, which SUCK [things like jquery and 'materialize']. The features in use from these are really trivial, somewhat easily done with custom style sheets, and working around their quirks and limitations has generated a few hours of GRIEF FOR ME, whereas if I'd written it myself from scratch it would've taken LESS TIME and cost the customer less.
Anyway, VENT COMPLETE on *THAT*. 'UX' indeed. What a bunch of touchy-feely B.S. THAT is.
Oh yeah after his final deliverable he got the "thank you for your service we'll contact you" e-mail. We even had MEETINGS with an outside management consultant over this guy, how to get him to produce SOMETHING and what was going on. Just confirmed my suspicions, but it also clarified the right path and I think it's ok now (aside from the grief) because product started shipping yesterday!
well - I _do_ admit that the screens look nice. Maintainability is another issue, but even so, they look nice.
No, this is the mistake a lot of software makes. There is nothing worse than software that looks good but does nothing well.
There's one thing worse: Software that looks like crap because some "designer" thought he needed to "make it look beautiful" without realizing that functionality is beautiful, and that works like crap too. Its the fastest growing kind of software today!
Umm, let's just agree to disagree about the UI for wordperfect for DOS, at least the non GUI version.
The only thing it had gojgn for it (and I must admit that's proven to be seriously major) was the ability to view the formatting codes. When some &%$$% idiots (I think it was Microsoft) introduced the idea of copying format codes along with text instead of defaulting to text only was when editors got so confused by unmatched codes that larger documents eventually refused to load.
Ironically, that was my main use of OpenOffice as a consultant: I rescued Word documents with it. Our IT department had, in its never ending effort to make more work for itself, come up with some mandatory format macros and any newbie making the mistake of using them quickly ended up in the quicksand of evil formats dwelling under the surface, copied all over the place with gay abandon.
A curse on whoever came up with that, because it wil have contributed to more man hours lost than even the introduction of the ribbon in MS Word. I would make him download and install Windows 10 with only access to a 300 baud rubber cup modem.
Not that it’s productivity software, but “shouldn’t change just for shits and giggles” would be a very useful design principle if applied to iTunes as well.
And if you want it banished to the nether pits that’s nothing that’s gonna upset me. I was only referring to its frequent cosmetic changes without much functional improvements or even feature changes.
The issue with Wordstar was that the shortcut keys were illogical Ctrl K X I think to save a document IIRC, which became more arcane the more facilities became bolted on.
WordPerfect for DOS was arguably more consistent in its use of function keys. As mentioned Reveal Codes was a genius masterstroke whoever thought of it (they should be as well-renowned as Mr Ctrl Alt Deli). Shame that Windows got rid of the "clean-screen" look (even WordPerfect succumbed). Nowadays it looks as if Microsoft are determined to half-fill screen real-estate with Ribbon detritus.
Anecdote time: I worked for a company where Wordstar was de rigueur. One day the secretary was busy deleting loads of documents on the boss's pc. "What are you doing?" I casually asked. "There's a load of documents that are just full of crud, so I'm getting rid them." What she was doing was opening them in Edit, seeing all the smiley faces (formatting to you and I), and deciding to delete them.
The WordStar shortcut keys were designed for the IBM PC keyboard, the one with the function keys on the left, and the control key immediately to the left of the A key.
On that keyboard the control key is very easy to find, and the X key falls naturally under index or middle finger while you are using the control key. The movement commands E,S,D,X were a direction diamond before keyboards got dedicated arrow keys, and the fast left/right movement keys were naturally A and F.
The direction diamond wasn't just used by WordStar -- it was in most software that required direction control from the keyboard. WordStar added the ^K prefix. That was easy and natural for touch typists, but wasn't used in games.
On the correct keyboard, the WordStar shortcut keys were incredibly natural and effective. Sadly, since they were designed to match the keyboard layout, when the keyboard layout changed they became unnatural and, to a certain extent ineffective.
But the shortcuts that didn't depend so much on the position of the left hand ~ ^KB ^KK, ^KV ~ still remained in use long after they had disappeared from the documentation -- the WordStar shortcut commands were silently supported by typing environments like MS Visual Studio for years afterwards.
> The WordStar shortcut keys were designed for the IBM PC keyboard
Wordstar and its command key combinations predated the IBM PC and its keyboard by several years. It was released for CP/M in 1978 following on from previous editors written by the same group.
> WordStar added the ^K prefix.
The ^K was for blocK commands. ^KB ^KK marked the start and end of a BlocK. ^KCopy, ^KmoVe, ^KHide, ...
> Sadly, since they were designed to match the keyboard layout,
They were designed to match a standard Qwerty keyboard years before your assertion.
"Standard QWERTY" keyboards didn't have control keys.
I take your point that the IBM PC keyboard was designed to match CPM keyboards, rather than IBM green-screen keyboards (which had the function keys across the top, where IBM returned them with the later keyboard layouts)
Our Kaypro keyboards had the control key to the left of the A key. This made the WordStar (on CPM) shortcut keys natural to type. When the keyboard changed to the PS2 keyboard layout, the WordStar shortcut keys were no longer nearly as natural. And when the keyboard got dedicated arrow keys, using the numeric keys on the right no longer required disabling the arrow keys.
> "Standard QWERTY" keyboards didn't have control keys.
Not on mechanical typewriters, no, but terminals since the early 1970s certainly did. The reference to QWERTY was, of course, to English keyboards rather than other languages where the various letters are not in the same place and the mnemonic meaning of the control codes are not so obvious.
I made no points at all about the IBM PC keyboard other than it had no place in the design of Wordstar controls because the design was completed years before there was an IBM 5150 PC*. The positioning of the function keys was irrelevant as Wordstar functioned perfectly without them (perhaps you were thinking of WordPerfect in this respect).
> This made the WordStar (on CPM) shortcut keys natural to type.
Whatever is felt to be 'natural' depends _entirely_ on what you are used to. I used Wordstar on CP/M with terminals having the Ctrl key next to the 'A' key and currently use Wordstar controls (on a different editor) with the Ctrl key on the lowest row. Both are entirely 'natural' to me. You obviously found it difficult to adapt and blamed the keyboard.
> when the keyboard got dedicated arrow keys,
Wordstar does not need arrow keys at all, neither on the numeric block nor as a separate block. That is what the 'diamond' is for.
* actually there were IBM 5100 Series machines in the mid 1970s which were intended as 'personal computers' but not named as such.
> Oops! Apologies for creating a passionate discussion.
I am not sure why you think it was "a passionate discussion".
> One of the things I liked about WordPerfect ...
So, you were confused between WS and WP in respect of the function keys!
Do you know what Alt= does in WordPerfect 5.x?
It works fine, and has never lost my data.
That's beautiful to me.
By comparison, Office - especially Word - is an ugly, ugly thing.
(I have lost more work to Word than to any other program I've ever used. And I spent 15 years of my career working with Lotus Notes. So that's an impressive and worrying statement to have to make about any software.)
The thing that drives me mad is the default that text copied and pasted from a Web page carries over the formatting, which has never, ever matched anything I would use in a document.
Has there ever been a practical use case for inserting HTML formatted text into a (professional) text document?
I've swapped the keyboard commands for "paste as unformatted text" and "paste" in my copy, and so far, that appears to persist between upgrades, even on MacOS.
In earlier versions of LO and OO that took running a macro, because someone had apparently decided that such a thoroughly useful command for "paste as text" should only ever be reachable from a menu selection, but as if (I think LO v5) it became a separate command which I immediately used to swap around with the usual paste command. Works like a charm.
Alas, the same person was in charge of deciding how accents should be entered. On a Mac, there is a keyboard entry process which allows you to enter accented characters, even if you don't have them directly on your keyboard, but OO/LO are the only applications available for Mac which wholly ignore that. The OO/LO approach for entry of accented characters is painful, from a UI perspective it's not a great success and 6.3 merely continues to plod along the same line.
The result is that it is not very usable for people who write in multiple languages on a Mac unless they install a Swiss keyboard which is a pain in the proverbial for programming (and you have to get used to QWERZ, but that takes less time than the accursed AZERTY that the French came up with, pardon my French).
Eh, I’m pretty sure git never loses anything once committed. As long as you can find the last commit hash - which is non-obvious if you’re back in time and it’s only displaying commits up to whenever you backtracked.
Advice: always do a commit, a git log and note the last hash and branch name before doing any weird stuff. It won’t save you on truly advanced stuff but will cover basic use.
Detached heads are a constant occurrence if you use ‘git bisect’ which is a git superpower.
And yes, the terminology and railroad diagrams leave me befuddled too :-(. I accept my near cargo cult status but mostly haven’t gotten bitten much.
Still looks like an early 1990s software program, they really need to work on the look and design to make it beautiful. Not just features.
It functions, and does it's job very well. That's more beautiful in MY eyes. Especially when you consider the Fugly-Flatso look that all the lemmings are so hyped up on these days.
Still looks like an early 1990s software program, they really need to work on the look and design to make it beautiful
When you say 'beautiful' you mean 2D FLATTY FLATSO McFLATFACE FLATASS FLUGLY like Win-10-nic, Office 365, and anything Chrome excretes. Am I right?
(I am SICK and FORNICATING TIRED of every @#$% "developer" jumping on THAT failing bandwagon...)
A big *THUMBS DOWN* for not recognizing the SANITY of a "classic" 90's style WIMP-friendly interface.
I use Libreoffice BECAUSE it doesn't slow me down with a useless crappy ribbon and other such nonsense.
I have only encountered one person who prefers the modern MS Word UI and she'd attended a MS Word course and was pissed off she now had to forget all the MS BS and use Libreoffice.
Libreoffice has very few limitations and many beneficial features vs MS. The only drawback I've encountered is the reduced maximum number of rows and columns in Calc vs Excel, but that was only once on a badly designed spreadsheet from someone else.
Yes, there is something worse than software the looks good but doesn't work.... and that is software who's UI CHANGES FREQUENTLY, whether it works or not.
edit: if I had just read one more comment before replying I would have seen that I'm not the only one who think that random UI changes are usually shit.
A great use for an old PC / Laptop is Wordprocessing for poor people.
A great shame. There are even some 64bit Atoms that only have 32 bit EFI. Those are harder to install 64 bit Linux on and often come with 32bit Win 10. Maybe in 10 years time would be reasonable to start dropping 32bit support.
32-bit builds removals
Binary Linux x86 (32-bit) releases will be demoted. There will be no Linux x86 builds produced by TDF after 6.2. This does not mean that Linux x86 compatibility will be removed. If you need a 32 bit build, please have a look at your distribution.
32-bit is dead, give it up.
The last 32-bit only x86 chips were the Atoms in 2010. Those machine are pathetic for anything vaguely modern, even when they were first released.
Sense the trend - 32-bit is dying across the board and has been for over a decade. Sure, you can do word-processing on an old DOS machine if you like. But when it breaks, you're gonna have replaced it with a 64-bit-capable machine unless it's literally not needed anything in the last 10 years.
To be honest, if people were after cheap, low-maintenance word-processor, I'd say buy a Chromebook. Offline editing, cloud-synced, simple-office-interface, automatic-saving.
Honestly... give it up. Even "old" 32-bit iPads are useless now - half the apps won't work.
Sorry Bob, had to downvote. I agree with regards 32 bit code being efficient and frankly perfectly fine, but there are a couple of aspects which make it difficult for me.
First of all, systems need to be 64 bit or 32 bit. It's a pain running both side by side. What's more difficult is having two architectures which means having to develop for and test both. I'd rather the people doing that were improving the code to be honest.
Yes, there are valid reasons to keep old hardware going but 32 bit really is getting on a bit now. I've got one old 32 bit box running arch32 with a few daemons and it's fine for what it does. It also has a copy of win xp on it (video capture card with no Linux drivers which I occasionally use). If you want a gui you can pick up an old 64 bit machine for peanuts now though.
Ultimately it's supply and demand. Once demand goes you'll find yourself marooned.
>First of all, systems need to be 64 bit or 32 bit. It's a pain running both side by side.
Don't really see the problem...
However, I do think many are getting confused between platform and OS requirements and application requirements.
Yes, the x64 platform, does allow more memory (and avoids getting tangled up with the i86 PAE implementation) and so more applications can run concurrently etc.
Hwoever, even today, having used x64 Windows since XP x64, I've not knowingly installed the 64-bit version of MS Office (and many other applications), nor have I run up against the memory limitations this imposes. I suspect my experience reflects the vast majority of Windows users, who we should remember are not employed by IT departments.
> What's more difficult is having two architectures which means having to develop for and test both. I'd rather the people doing that were improving the code to be honest.
How ironic then that Microsoft has been working on Windows 10 on ARM which is intended to have x86 32bit only emulation. You will then have 3 architectures (or maybe everyone will simply ignore Windows 10 for those devices).
32-bit is dead, give it up.
W R O N G ! ! !
I think the real reason why 32-bit is dead on the mainstream desktop is because maintaining 32 and 64 bit code is "too difficult" for snowflake developers.
Remember it was the snowflakes who decided that learning multiple programming languages was too difficult and hence everything should be coded in C, VB or whatever was the fashionable programming language of the moment.
"32-bit code will actually run a bit FASTER than equivalent 64-bit code, if for no other reason than the instructions and pointers are smaller, which means LESS memory has to be read into the cache, and so on."
Hogwash. If you've ever taken a look at Intel assembler, loading an address into a register is a single instruction. That's true regardless of whether the address is 32-bit or 64-bit. Next, loading a memory location *from* the address in that register is *also* a single instruction, again regardless of whether the address is 32-bit or 64-bit. So, the only possible difference would be in how that 32-bit or 64-bit address got into memory in the first place. And since memory is loaded in multiples of pages, and NOT individual 32-bit or 64-bit values one at a time, there will be no difference is the amount of time spent loading the 32-bit or 64-bit addresses into memory (which may be zero in either case, if the address is derived from a previous operation and already in a register.)
Now, having said all that, if you've got some degenerate case in which for some reason millions of addresses are stored in memory, then sure, each additional million will use up 32 MB of memory. I can't conceive of how this would happen, but don't deny the possibility. This will likely have an measurable impact, though if you are dealing with such a case, you are probably anticipating the issues involved.
32 bit numbers take up twice the space of 64 bit numbers. They require twice the memory, which takes twice as many pages and is twice as likely to spill across a page boundary. And they take twice as many lines of RAM, and are twice as likely to spill across a line boundary. When your RAM runs at the same speed as your cache, and your cache runs at the same speed as your registers, then you can tell me this has no effect.
I'm using existing 6.2.x on Linux Mint 18.3 and Linux Mint 19.x (19.1?) and 5.x on Linux Mint 18.3:
I don't see anything about improved docx or ms doc support. There are bugs to do with styles even after conversion on import or on Save As.
Publishers and some ebook creation tools want MS docx or MS doc. You have to "Save As", exit LibreOffice, open the MS format doc, fix style errors and Save (not Save As), also "forgets" embed font setting in . Then not open without fixing all again.
Please stop with GUI fiddling and concentrate on function. Though Mozilla, MS and Apple are worst on that.
PDF is for print ready paper. I ONLY upload that for production to print. Like POD services
PDF is absolutely EVIL for ebooks, editing etc. An actual Publisher will NEVER want PDF unless they are crazy, printing it on paper and not editing / formatting.
The ebooks are not ebooks if using PDF. You can't sensibly create anything from a PDF except a printout. Best format to upload to Amazon for ebooks oddly is epub v2, they then convert to old mobi, KF8 /azw3, KFX etc according to the Kindle device/app the buyer has.
Unless you are using Sigil, you need to Save As MS docx in LibreOffice and then convert that to epub using Calibre. The LibreOffice 5.x plugin and the 6.x built-in epub export is no use except for simple trivial ebooks, no good for publish ready ebooks.
Digression, but had to write it:
1st thing I did with my new old Kindle is to jailbreak it - to get read of azw3 bs limitation. Epub is what I am using, in 90% cases.
Sigil & Calibre are great, but for more professional design you should check Scribus (it does have epub export iirc); Pandoc should be of great help too.
If a publisher wants a .docx from me, they can find someone else.
A publisher who wants formatting can get a PDF, a publisher who prefers to format themselves will not be interested in layout as that is their job and thus Word would only get in the way.
It's this bizarre focus on format instead of contents that got people to needlessly update in the first place. It was quite a con for Microsoft, and totally astonishing for people who know how to write content, not produce empty headed DTP.
>It was quite a con for Microsoft, and totally astonishing for people who know how to write content, not produce empty headed DTP.
I think the focus on content rapidly disappeared when WYSIWYG became fashionable. Word for DOS (well 3.0 through to 5.0) allowed you to focus on the content. Draft view in the Windows versions doesn't come close. Additionally, you could display the formatting codes and so quickly resolve formatting strangeness.
I like RTF for that too, despite it being Microsoft proprietary. At least with RTF you know that the formatting is more or less intended. Unfortunately, people won't use it for the same reason they persist with bad formatting – they have no clue about "all this technical stuff". (Even when it's supposed to be a part of their job.)
"I'm using existing 6.2.x on Linux Mint 18.3 and Linux Mint 19.x (19.1?) and 5.x on Linux Mint 18.3:
I don't see anything about improved docx or ms doc support."
Might that be because ... let's see now ... reads headline ... this article is about 6.3, not 6.2.anything or 5.anything?
You can do crazy stuff in spreadsheets thats hard(er) in code. Data munged about and then, for a few particular data points, replace the code with static data or some other function. Dealing with exceptions like that is hard in code.
Data is more visual so you can spot trends and problems easier than with code. Graphing visualizing data is often quicker in spreadsheets than with code.
I'm sure FOURIER is there cos people asked for it.
I've seen mad complex spreadsheets in banks.
I can think of MANY reasons to do a fourier transform in a spreadsheet, and I have done fourier transforms on data MANY times.
It spots cyclical trends. That's why.
CYCLICAL TRENDS are important, naturally occuring. Seasonality is a good example of ONE cyclical trend, people buying certain kinds of things at Christmas time. Yeah I called it Christmas instead of "winter holidays" and a big F.U. to people who want to complain about it.
So yeah, Fourier Transforms, a welcome feature.
Point is, if I do a spreadsheet of sales data per month, or per day even, and run a fourier transform on it, I might be able to spot trends that can affect how my financial decisions are made.
I'm just wondering why someone would want to do a fourier transform in a spreadsheet.
Because a spreadsheet makes a good grid control ... and sometimes you want to display things as a grid.
Years ago, I was doing some firmware changes for a company that made security hardware for banks. One bank had a particular requirement for custom functionality, and I coded that.
I had to produce some test data ... I had a C library that did DES encryption (yes, it was that long ago) and I imported that into Excel and wrote a VBA wrapper around and performed binary-to-hex conversions on strings. I was able to put together a spreadsheet into which plaintext test data could be plugged to get the correctly formatted test command for the box and the correct response (assuming the box had standard test keys loaded). It wasn't the best way to put together a test suite (!) but it worked and the suits who had to OK the tests understood Excel.
So, no, FT doesn't have to be built into LO Calc because one can always use the same trick to add it as I did for DES ... but I guess enough people asked for it that it seemed worth adding, and I guess one or more developers thought it would be satisfying to code.
Can't speak for fourier, but I recently set up a spreadsheet to pack a long list of bytes valued 0-3 into 2-bit pairs into a proportionate smaller list of 32-bit values (in hex). I certainly could have done it in Python, or likely even BASH, or even written a GIMP plugin to do it (since the source was a 2-bit greyscale pixmap and the dest. a Rust array) but doing it in an OO Calc was just quicker and easier for the task at hand.
One of the first spreadsheets I wrote was for Fourier series analysis of non-linear distortion in amplifiers. Prior to that, I drew out a matrix of rectangles on a piece of paper, and banged out the contents of each cell on a calculator. I am a bit nerdy about Fourier transforms. Bloody useful stuff. One of the first programmes I wrote in C on my first home computer was an implementation of the Fast Fourier Transform (FFT), based purely on a couple of pages in Bracewell's excellent book. I did not understand malloc and pointer doodahs, so all the arrays were on the stack, but it worked.
"There are now also browser-based options, including Google's G Suite, but if you prefer the freedom of working locally with open source software, LibreOffice is for you."
There are now also browser-based options, including Google's G Suite, but if you prefer not to let Google sift through your documents and sell the data to advertisers, LibreOffice is for you.
I still cannot exchange (text)files with LibreOffice Writer without having problems with font naming and related font substitutions, sometimes catastrophically. Trying to repair the issues via its stylesheet system is extremely work intensive, and confusing (there are at least two separate style sets attached to a unit of text, with different sets of priorities which one gets applied depending on the workflow you use.)
On top of that it is ugly in multiple ways, can easily be set to a theme that renders parts of it illegible, and frequently slows down to a crawl. I shudder very time I have to use it. It's worse than Microsoft's beasties.
So for me, when using text files across different file formats, it is far better to use Nisus Writer. It uses the LibreOffice im-/exporting system, but does not have these problems.
> The origins of the project go right back to the '80s, when it was a commercial office suite called Star Office.
Before that, Star Division were selling a cross platform GUI library called StarView. As a demonstration of how useful that library was they included a word processor and a spreadsheet written using the library. Later, these were sold separately for various machines.
The LO equivalent, under development deep in the TDF skunkworks, is called Stapley. When you let Stapley "help" you, you won't be able to undo the changes it makes, because it can't possibly have come out differently to what you wanted, right? Stapley knows best.
A couple of years after Stapley is unleashed, a motivated bedroom-coder will release a plugin called Staple-remover-y, which obliterates anything Stapley did that actually _did_ align with what you wanted, but still leaves your pages warped and slightly torn.
In the meantime, the user community will get used to a workaround which, had anyone the inclination to give it a name, would probably be called Reprint-the-whole-thing-and-just-use-a-paperclippy.
IIRC, when Microsoft was asked why the ribbon was obligatory--why they couldn't make it possible to use either the ribbon or the old menu--the reply was that it was too much work to maintain both. That always seemed bogus to me.
Now for LibreOffice we read: "there are now a bewildering number of options for menus and toolbars. You can select Standard Toolbar, Single Toolbar, Sidebar, Tabbed, Tabbed Compact, Groupedbar Compact, and Contextual Single. You can also combine various options, such as choosing Tabbed UI, which is reminiscent of the Microsoft Office ribbon toolbar, and then adding the traditional dropdown menubar on top." So what Microsoft couldn't do because it was too much work, the LibreOffice developers are doing, and then some.
(I do suspect the Microsoft reason was really an excuse.)
Biting the hand that feeds IT © 1998–2019