Shorty table: Presentation, filtering, sorting.

[fredl99]

Follow-up from here

[arkascha]

@fredl99 Sorry, you confuse me :-) What exactly is the issue you want to address here separately?

Guess this confusion teaches both of us to take more care with keeping separate issues separate :-)

[fredl99]

At the end of the 'maximum length of URLs' thread we were discussing the look and functions of the table. Since this has nothing to do with the original issue, which was solved anyway, I thought it's a good idea to close it and open a separate thread. Didn't mean to confuse you but rather the opposite. :)

[arkascha]

Ah, I see. I confused the term "Tracking table" with the table in the Tracking extension of Shorty :-)

[fredl99]

I renamed the topic in order to eliminate further confusion :)

Here are some thoughts:

• Is it possible to completely hide any unwanted column instead of minimizing it, as it usually becomes unreadable anyway?
• Since that would require a function to recover it, would it be possible to chose from a list of available data fields to be shown/hidden in the table view? At the moment the "notes" field doesn't show up anywhere, for instance.
• An extra bonus would be, if the order of the columns could be changed :) With all the above a user could create his very own personal table view.
• Any way of separating Shortys into different categories would be great. Similar to folders of bookmarks. Either by a header line or a plain horizontal rule.

[arkascha]

Separated the last bullet into #95.

[arkascha]

I see the other three bullets as constructive suggestions.

Indeed this would lead to a much more flexible layout, a better customization of the app. On the other hand one has to take care not to get lost in a feature mania. Shortys UI is already cluttered with am unmatched feature density compared to other OC apps.

So I'd like to leave this as an enhancement suggestion without taking action right now. Priority lies with the upcoming version. This might be a very interesting thing for others starting to contribute!

[fredl99]

Don't know if this fits in here, but we had some issues with special characters in the title field when a shorty is created. There is still a problem:

With a click on the middle line the title is also set to correct characters.

---

BTW: Notice the empty square in the middle line? I'll emphasize on this in the other thread.

[fredl99]

Sorting by creation or expiration date seems broken at the moment (latest commit 33893f6e8289d6332facc6a24aab72b46cac4175) Looks like this:

[fredl99]

N.B.: When clicking any of the "date" headers, only the columns themselves are sorted, not the entire lines...

[arkascha]

I pushed some more small fixes last night. Amongst those was 347aa7747419ee62829fa2f0e15b66272a4bbf04 which should fix the issue, which indeed I only saw late last night myself. Wanna give it another try? Thanks!

[fredl99]

Ok, so I'll switch back to owncloud/shorty, because from arkasha/owncloud-shorty (which I was following all the time) I didn't receive this commit.

I will go on testing.

[fredl99]

Well, the lines do entirely follow the sorting criteria in this version. But the sort algo itself is working as described above. Looks like "sort the year numbers, then the month numbers within the year, and then the day numbers within the month". (The last one in the opposite direction, just to spice it up a little :grinning: )

I have only five entries with a "last access", so I can't be sure if this column would also be sorting like this.

[arkascha]

Sorry if I caused any confusion... Just checked, the commit is present on both my private clone and the official repository. I keep both completely in sync currently. However I just realize that indeed the sha's are different between branches master and stable7. I actually do not really understand why... But the commit is present in both branches on both repositories. No idea why you could not pull it...

[fredl99]

So I should checkout "stable7", like I asked earlier? I'm at master now.

[arkascha]

As mentioned they are kept completely in sync currently. So for now it simply does not matter. However: Stable7 will fall behind later, so probably it makes more sense to use Master from now on for testing.

[fredl99]

Sorry, I didn't carefully check the received commits. Yes, 347aa7747419ee62829fa2f0e15b66272a4bbf04 is here. But the sorting is as I described above.

[arkascha]

@fredl99 Sorting should be fixed now, at least it looks logical to me. Any exceptions?

[fredl99]

Hm, don't know... Expiration date is ok in both directions:

Access time seems to work, too. But I don't have so many samples.

Creation time is still a bit weird: Left: descending, lower end | right: ascending, upper end |

See what I mean?

[arkascha]

@fredl99 Better now? Found some undocumented option...

[fredl99]

Perfect! :+1:

I wonder why there's a secret option needed with the creation dates, but not with the expiration dates. For my eyes they both seem to contain similar data. OTOH: not my business :smiley:

Now if I only could turn columns completely off and on :whistle:

Thanks again for the continuing improvements!

[arkascha]

The issue appears to be some internal voodoo magic in the tinysort library I use. Apparently it tries to interpret the last "-nn" as negative number, which explains the strange sorting order. I can only guess that does not apply to the other columns because of different formats... But you are right, it probably is safer to apply the same option with the expiration date too... The access date is a different thing - it is internally stored as a number (a timestamp) which is always sorted correctly, since there is no room for interpretations.

[fredl99]

The access date is a different thing - it is internally stored as a number (a timestamp)

So why not use the same method for all of the dates? Unwanted time-of-day portions could easily be chopped off. But as the columns are collapsible anyway, it wouldn't matter. The code would be easier to maintain and, as we saw, it causes the least problems. (As long as timestamps are converted correctly :smiley: )

[arkascha]

The reason at hand, though I certainly grant that this is a situative argument: this would require database migration steps which adds more issues to deal with. Sorting worked before, it was only crippled by upgrading the bundled tinysort library which introduced mentioned voodoo magic.

I am currently more concerned in getting out a working version at all. This project already swallows far to much time. Sorry. This might actually be a good starting point for code contributions. But I myself simply have to protect myself from this getting bigger and bigger. Don't get this wrong, but the impending penalty would be that I have to drop this project completely, which would be a really bad outcome. In the past I learned to chose the battles to fight. Sometimes it is easier to act in a programmatic manner. Though that was a hard lesson to learn, I have to admit :-)

[fredl99]

I'm completely with you and your arguments. I do respect the extra effort you put into this project during the past weeks/months, especially since you already have announced the need for collaborators longer ago.

If I only had experience with that technology, I would certainly contribute some code. But my skills are of other sorts. I really wish, some educated coders would jump in here.

My suggestions are therefore not addressed to you personally, but to anybody who feels able to implement them. It wouldn't make sense to keep them for me, just because you're still the only one who cares about them. So I simply write down my ideas when they appear.

[arkascha]

All fine, I would suggest to maybe separate such details into separate issues here on github and mark them as 'enhancement'. That way potential contributors can easily spot such junior jobs and start right away without having to dig through endless exchanges.