Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Luckysheet, an open-source spreadsheet

github.com

Post reply on HN
Print view View original

81–90 of 123 posts

Re: Luckysheet, an open-source spreadsheet

#81

Post by doodpants »

asah wrote: post #57
smartmic wrote: post #26

I still cannot wrap my head around why so many folks want to use such applications in a web browser. For me, web browser applications never reach the responsiveness and ease of use of well crafted desktop applications written in any decent systems programming language or even interpreted languages (not speaking of Javascript). Maybe I am getting old, but having the browser as a platform for programs is huge setback f…

No installation Multiple tabs/windows Don't leave the browser Works-at-all on multiple platforms incl mobile Deep linking / sharing / bookmarking App freezes are less common (on network access) and easier to manage when they happen - obviously this is anecdotal and not universal.

> Don't leave the browser

For someone saying that they don't like browser-based apps, how is this an advantage? They're presumably not in a browser in the first place.

Re: Luckysheet, an open-source spreadsheet

#82

Post by kevincox »

fbrchps wrote: post #72
alpaca128 wrote: post #66

Earlier 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'…

You need to back up your hard drive too.

The point is that you always need to back up. Sure, if you pay Google you can probably rely on them. But it is still best to backup anyways.

Re: Luckysheet, an open-source spreadsheet

#83

Post by microcolonel »

cosmodisk wrote: post #59
chrismorgan wrote: post #53

I will keep saying this every single time some one gets this wrong (which is at least 49 times out of 50): the only way to handle scrolling properly on the web is for your scroll events to fall onto a real scrollable area, and to observe the effect it has (e.g. apply the scroll position to what you’re rendering with). This can be tricky to achieve well when you have dynamic content that the mouse needs to be able to…

Do you happen to have some links to resources I could read a bit more about it?

There are some intricacies about when to reset the scroll position, if ever.

Here's one way: https://codepen.io/xorgy/pen/yYdVoY

Re: Luckysheet, an open-source spreadsheet

#84

Post by microcolonel »

chrismorgan wrote: post #53

I will keep saying this every single time some one gets this wrong (which is at least 49 times out of 50): the only way to handle scrolling properly on the web is for your scroll events to fall onto a real scrollable area, and to observe the effect it has (e.g. apply the scroll position to what you’re rendering with). This can be tricky to achieve well when you have dynamic content that the mouse needs to be able to…

With infinite scrolling, you can also just set the container to be absolutely huge, and use the scroll position to index. This works especially well for computed layouts like tables, where culling rows and columns is a simple scan over run lengths of row and column sizes.

Likewise if you know things will be inserted at the top of a scroll view, you can pre-allocate above the “top”.

The one thing that is hard to do well (but less hard now with new CSS features I think) is scrolling that feels good but always ends with the border of a cell being aligned to an edge of the scroll view (the Excel behaviour).

Re: Luckysheet, an open-source spreadsheet

#85

Post by feteru »

nn3 wrote: post #79
alpaca128 wrote: post #66

Earlier 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?

And Google uses some badly tuned and not understandable by humans, and also constantly changing, machine learning algorithm to decide to serve you or not. When something goes wrong with this, you have a a fairly small chance that you can reach a human to override, but it will be an overworked underpaid contractor somewhere and your chances will be poor. If you talk long term (decades), it is quite possible that Googl…

I think it's foolish to shoot down advantages in practicality and fluency of use on the basis of a decades long event for the vast vast majority of use cases. My company hasn't been around for decades and we don't use any particular spreadsheet outside of a select few for more than a couple months at a time. You'd lose all credibility arguing against G-suite on the basis of losing your data/getting your enterprise google account banned, because it would cost the business so much time and confusion relative to the ease of cloud solution.

I've already had disks fail, never had an issue with Google Docs being down, and if it happens I think it will have been worth it.

Re: Luckysheet, an open-source spreadsheet

#86

Post by app4soft »

bmn__ wrote: post #55
app4soft wrote: post #39

Earlier quoted context omitted.

> For example, as a free Excel alternative, I fall back to Gnumeric ( http://www.gnumeric.org/ ) from time to time. Gnumeric is useful, but its GUI is very laggy (more laggy than LibreOffice Calc). Sadly, there NO fast & usable Qt-based alternative to Excell for Linux yet. As lightweight spreadsheet app for Linux I use Qt-based mtCellEdit [0], which does not support .xls/.xlsx formats & could not fully replace Excell…

https://calligra.org/sheets/

Is there Qt-only (KDE-free) version of Calligra Sheets?

Re: Luckysheet, an open-source spreadsheet

#87

Post by chrismorgan »

robbiejs wrote: post #56
chrismorgan wrote: post #53

I will keep saying this every single time some one gets this wrong (which is at least 49 times out of 50): the only way to handle scrolling properly on the web is for your scroll events to fall onto a real scrollable area, and to observe the effect it has (e.g. apply the scroll position to what you’re rendering with). This can be tricky to achieve well when you have dynamic content that the mouse needs to be able to…

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 too, most significantly because it doesn’t look native and may offer different functionality from the normal scrollbar. You can’t win, the web doesn’t give you the tools you need to get the experience perfect.

But yeah, your example in DataGridXL is a good example of the right approach to take for this if you want scrolling to be done in steps as is conventional in spreadsheets.

Re: Luckysheet, an open-source spreadsheet

#88

Post by chrismorgan »

microcolonel wrote: post #84
chrismorgan wrote: post #53

I will keep saying this every single time some one gets this wrong (which is at least 49 times out of 50): the only way to handle scrolling properly on the web is for your scroll events to fall onto a real scrollable area, and to observe the effect it has (e.g. apply the scroll position to what you’re rendering with). This can be tricky to achieve well when you have dynamic content that the mouse needs to be able to…

With infinite scrolling, you can also just set the container to be absolutely huge, and use the scroll position to index. This works especially well for computed layouts like tables, where culling rows and columns is a simple scan over run lengths of row and column sizes. Likewise if you know things will be inserted at the top of a scroll view, you can pre-allocate above the “top”. The one thing that is hard to do we…

CSS Scroll Snapping may have a place for image gallery sorts of widgets, but for broader layout matters I strongly recommend against it: it can work tolerably on mobile (though it’s not without problems), but on desktop it seriously messes with scrolling so that on many devices it’s almost entirely problems.

(That’s what I said at https://news.ycombinator.com/item?id=23915285 which was dealing with much the same area.)

Instead, you’ll want to implement such snapping with absolute snapping as seen with robbiejs’s example.

Re: Luckysheet, an open-source spreadsheet

#89

Post by robbiejs »

chrismorgan wrote: post #87
robbiejs wrote: post #56

Earlier 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…

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 mobile too.

Re: Luckysheet, an open-source spreadsheet

#90

Post by blntechie »

robbiejs wrote: post #89
chrismorgan wrote: post #87

Earlier 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…

Your implementation is pretty neat.

We recently kind of went down the path of our own scroll bar in one of our app forms because users wanted the scroll to behave in a very specific way. It was impossible to make it work as expected in all the OS and browsers. We eventually rolled back the change, restored the native scroll bar and instead provided a big optional floating scroll button in the bottom corner of the app which user can choose to use to scroll the way they expected to. Kept everyone happy.

Post reply on HN