Recently I've become addicted to sc-im, a vi (vim) like spreadsheet. Using this tutorial: http://blog.startaylor.net/2016/08/29/sc/
While I don't do very complex things, in terms of note taking using a spreadsheet, it's excellent.
Luckysheet, an open-source spreadsheet
91–100 of 123 posts
Re: Luckysheet, an open-source spreadsheet
#92Earlier quoted context omitted.
Absolutely. In the development process of our product DataGridXL we've also experimented a lot with "scrollwheel" events and such, for months really. It's just not possible to get it to feel natural. You might be able to get it working nicely on one specific OS+browser combo, but that's about it. Always listen to the native "scroll" event: https://www.datagridxl.com/demos/one-million-cells
One deficiency of using the native scrollbars visually here is that the arrows at the end of the scroll bars on some platforms (e.g. Windows, most Linux) will scroll by a predetermined number of pixels, more or less, whereas in such an application you would probably prefer it to scroll one column horizontally or one row (though maybe more than one) vertically. Of course, placing your own scrollbar visuals is a hazard…
> whereas in such an application you would probably prefer it to scroll one column horizontally or one row (though maybe more than one) vertically.
But isn't this exactly what element.scrollIntoView() is supposed to be for?
Native scrollbars, styled with scrollbar-width and textareas resizing with cols attribute is pretty straight forward if you do the box-sizing right.
Re: Luckysheet, an open-source spreadsheet
#93Earlier quoted context omitted.
I can't see why more options to choose from is not an advantage.
More options is good for rapid evolution of a new domain. Eventually though, we need collaborative effort to take established ideas to a mature state. For example, there are a number of fledgling open-source nonlinear video editors (NLEs) -- to name a few in no particular order Kdenlive, Openshot, Olive, OpenMovieEditor, Blender Video Sequence Editor, Shotcut, Cinelerra, and Flowblade. I say this with full respect to…
+1 for the NLE example, as it's one of the biggest problematic areas to me. What even is the difference between Shotcut and OpenShot? Both are 90% of the way to being the perfect everyday video editor, yet they both get destroyed by the first shareware result for "free video editor" when it comes to polish.
But we really can't blame the authors - there's no money in open source user apps and polishing isn't fun to most people. I'd immediately jump on the opportunity to build an NLE from scratch if given the time and financial freedom, but I can't see myself digging though someone else's code and sanding all the rough edges for fun.
Re: Luckysheet, an open-source spreadsheet
#94Language files blank comment code ------------------------------------------------------------------------------- JavaScript 142 54627 91825 243672 CSS 9 790 238 5908 HTML 2 10 1 43 ------------------------------------------------------------------------------- SUM: 153 55427 92064 249623 ------------------------------------------------------------------------------- without the demoData dir. that's nuts
It's closer to 90k lines of JS if you exclude data and external libs, those directories: data locale demoData expendPlugins/chart plugins
Ah good catch. A little more reasonable for a 1-person project then.
Re: Luckysheet, an open-source spreadsheet
#95Earlier quoted context omitted.
Registration/Login required(I'll take the installation over that in many cases) No properly working (or even implemented) keyboard shortcuts; I just tried, Google Sheets tells me to use Ctrl+C etc. but it doesn't do anything, and what's even worse is that the menu item for "insert" doesn't do anything either because Google wants to force me to use the dysfunctional keybinding...thanks I guess Usually no right click +…
I understand the sentiment, but some of your points are simply not true. Ctrl+C works fine last time I tested GDocs (inc sheets). It also have offline support, and supports right clicking? Input lag is very dependant on the actual application and how it's made AFAIK, albeit it might be more difficult to do it right using web tech. That leaves two arguments (basically privacy arguments). That is not it related to web…
> Ctrl+C works fine last time I tested GDocs
Well, it didn't work when I wrote my comment, sorry that it seems to be inconsistent on my setup. Regardless it is still very questionable of Google to make the "insert" menu item do absolutely nothing but show a popup dialogue telling you to use Ctrl-V. It is annoying and comes across as a bit condescending, like some engineer at Google wanted to teach the noobs how it's done properly.
> It also have offline support, and supports right clicking?
I was talking about web apps in general, not just Google. Many web apps don't have any context menu or shortcuts, you have to move the mouse back and forth all the time for the simplest steps.
And what's even worse is that many JS-loaded websites mess with the UI so much that you can't open links in new tabs anymore. I don't even want to know how that can be done unintentionally.
> Adobe CC more or less requires the same login and authentication requirements as other web applications.
You are right there, maybe I conflated the web app trend with the rising amount of user-unfriendly software design.
Re: Luckysheet, an open-source spreadsheet
#96Earlier quoted context omitted.
> No need to backup You trust Google etc. to never ban your account for any reason, or to stay available 100% of the time without outages?
You trust your hard drive to never fail during crunch time, or Jane Doe in accounting to not lose the flash drive that gets shared around the office every quarter? I'd take "generally highly available" vs "trusting my local copy" almost all the time. And as for using something like a Git'd Excel document: most people won't do that, and Github can go down, too. Just because Google Drive isn't perfect, doesn't mean it'…
It's not an either-or. My argument was for making backups, not
cloud vs. local storage.
Re: Luckysheet, an open-source spreadsheet
#97I wish people wouldn't copy Excel (or Google apps for that matter). Those spreadsheets are terrible . It still baffles me that none of them can do sideways scrolling correctly, they are all incredibly awkward to edit, the formulae are fundamental to how they work yet hidden and obscure, they do weird "magical" stuff to strings like turning them into numbers or dates when you didn't ask, etc. I'd really like to see pe…
When you say 'has the functionality of a spreadsheet but looks nothing like current spreadsheets', what do you mean? I am working on Mesh Spreadsheet. It gives you a spreadsheet UI that writes code as text. It will likely use k9 as the formula language once it matures, but: - you can try the JavaScript prototype at this link: http://mesh-spreadsheet.com - you can see a proof of concept video using k here: https://www…
Hi, what's K9? My Google searches in combination with "formula and/or language" gave me only dog related results.
Re: Luckysheet, an open-source spreadsheet
#98Earlier quoted context omitted.
I understand the sentiment, but some of your points are simply not true. Ctrl+C works fine last time I tested GDocs (inc sheets). It also have offline support, and supports right clicking? Input lag is very dependant on the actual application and how it's made AFAIK, albeit it might be more difficult to do it right using web tech. That leaves two arguments (basically privacy arguments). That is not it related to web…
> Ctrl+C works fine last time I tested GDocs Well, it didn't work when I wrote my comment, sorry that it seems to be inconsistent on my setup. Regardless it is still very questionable of Google to make the "insert" menu item do absolutely nothing but show a popup dialogue telling you to use Ctrl-V. It is annoying and comes across as a bit condescending, like some engineer at Google wanted to teach the noobs how it's…
The insert menu tells you to use the shortcut because browser restrictions make accessing/modifying the clipboard without doing so difficult.
Re: Luckysheet, an open-source spreadsheet
#99Earlier quoted context omitted.
One deficiency of using the native scrollbars visually here is that the arrows at the end of the scroll bars on some platforms (e.g. Windows, most Linux) will scroll by a predetermined number of pixels, more or less, whereas in such an application you would probably prefer it to scroll one column horizontally or one row (though maybe more than one) vertically. Of course, placing your own scrollbar visuals is a hazard…
> whereas in such an application you would probably prefer it to scroll one column horizontally or one row (though maybe more than one) vertically. But isn't this exactly what element.scrollIntoView() is supposed to be for? Native scrollbars, styled with scrollbar-width and textareas resizing with cols attribute is pretty straight forward if you do the box-sizing right.
I think you’re misunderstanding. I’m saying that on platforms where the native scrollbar has arrows that you can click to scroll by a small amount in the nominated direction, you might prefer clicking on those arrows to do something different—to scroll one row or one column, whatever distance may be, rather than however many pixels the user agent decides. But you can’t do that on the web.
element.scrollIntoView() is completely unrelated to this.
Re: Luckysheet, an open-source spreadsheet
#100Earlier quoted context omitted.
One deficiency of using the native scrollbars visually here is that the arrows at the end of the scroll bars on some platforms (e.g. Windows, most Linux) will scroll by a predetermined number of pixels, more or less, whereas in such an application you would probably prefer it to scroll one column horizontally or one row (though maybe more than one) vertically. Of course, placing your own scrollbar visuals is a hazard…
You know your stuff, I can tell! In a pre-release version, we had hidden the native scrollbar and put our own scrollbar graphic on it that would animate using CSS transform according to native scroll offsets vs. DGXL viewport dimensions. The scrollbar size (width/height) and position made more sense, but at the end we couldn't get it to feel quite right. We're quite happy with the native scrollbar. It's fine on mobil…
Yep, I think native scrollbars is reasonable for DGXL. Maybe eventually you’ll sniff whether scrollbars take space and draw your own that match the size if they do, but it’s definitely a little risky.
These sorts of things are particularly interesting once you support a sparse spreadsheet; drawing your own scrollbars becomes much more compelling then, so that you can make them more useful. No idea about Excel, but LibreOffice Calc—(which amusingly gets scrolling by precise touchpad wrong in just the same way as Luckysheet, sans the wrong horizontal direction; this stuff is hard everywhere)—well, LibreOffice Calc’s scrollbars essentially pretend the whole time that the document is only as large as the extent of the cells with content or the selection, whichever is larger in each axis, plus a screenful or so in each axis. So if you’re at A1 of an empty document, the scrollbars thumbs fill about half of the bar, but if you’re at AMJ1048576 (maximum sheet dimensions are 2¹⁰×2²⁰), the thumbs are tiny at the bottom and right.