Change the app title to show more relevant info of the edited document's status

[junrrein]

From https://github.com/junrrein/pdfslicer/issues/30#issuecomment-489116521:

remove the title "pdf slicer" from the headerbar and keep only the open pdf name as only-&-main title. I know, I know, you're proud of your software, and I can definitely tell you that the user knows what he's using since the app-title is shown on gnome-black-topbar already. :)

[junrrein]

@amivaleo

I like to think I'm not that kind of proud about the app :) I agree on this point.

[amivaleo]

Oh, c'mon! :D

I've very little experience as a programmer, but I really feel satisfied when my tiny scripts (mainly for plotting graphs/histograms usint ROOT and c++) work flawlessly. :) Your app is on gnome-software and can become a very nice and modern alternative for other pdf editors (pdf-shuffler, pdf mod, etc).

[I hope you will consider some pdf metada editor app one day]

Anyway, don't forget this part:

IF others pdf files are added to the original one, the title should show a subtitle "added file NAME_FILE.PDF" if only one file is added, or "multiple files added" if more than one file is added

What's your opinion about this?

Sorry, I read your answer to this ( https://github.com/junrrein/pdfslicer/issues/30#issuecomment-490274896 ) after replying here.

[junrrein]

@amivaleo

I've very little experience as a programmer, but I really feel satisfied when my tiny scripts (mainly for plotting graphs/histograms usint ROOT and c++) work flawlessly. :) Your app is on gnome-software and can become a very nice and modern alternative for other pdf editors (pdf-shuffler, pdf mod, etc).

Well yeah, I'm proud of this app since I've already reached the goals I had when I started to write it. I'm not so proud of it that I need to remind the user it's using it. Even if I had that need, it would be best served by other means, like having a watermark of my face as the background of the app :grin:

And this app is very much inspired by pdf-shuffler and pdf mod, so I would like to think Slicer as a spiritual successor of them.

[I hope you will consider some pdf metada editor app one day]

That probably won't happen, since it's not a need that I have.

Now, about other changes to the app title:

• add an asterisk ( * ) at the beginning of the title when the open pdf has unsaved changes, like other apps do (gedit, gimp).

I agree with this, good suggestion.

• IF others pdf files are added to the original one, the title should show a subtitle "added file NAME_FILE.PDF" if only one file is added, or "multiple files added" if more than one file is added. In this way, if the user click on the "save" button, he will overwrites the original pdf.

I agree with this except for the part about overwriting the original file, but we are already talking about that at #30.

• IF other pdf files are added, every page should show a two-rows label. The top row should be the name of the file that page comes from. The second/bottom row should be the original page number. So that the user could recognize both the origin every page and its number.

This is a great idea. I currently had this imagined (and implemented in master!) as two labels side-by-side where the page number is already shown, but there is little space for the file name here. It made the interface feel crowded. Having those one under the other will be better.

[amivaleo]

having a watermark of my face as the background of the app

Consider that gimp has its coyote EVERYWHERE... I made a mockup for gimp, using headerbars and all the stuff, in which I got rid of that animal entirely. No one liked it. 😄

That probably won't happen

You've just broken my heart...

I agree with this except for the part about overwriting the original file, but we are already talking about that at #30.

Yep, yep. Indeed, I read the other thread after posting here. ;)

It made the interface feel crowded

Do not reinvent the wheel, try to get/copy ideas from what other apps do.

Here, for example, this "two-label-rows" comes from nautilus. :)

[junrrein]

@amivaleo

Current state:

When a single file is opened:

When one file is added:

When another file gets added:

I took care to ensure that app title, subtitle, and page labels get updated correctly when undoing these operations:

Any observations? Is the app subtitle capitalized correctly?

[amivaleo]

A couple of things:

1. What do you think about linking open-button and +-button? 🤔 This could be a cra*py idea, just wondering if it makes any sens.

2. Not fully sure that not showing the page number of the added file is good enough. Right now, at the bottom of added files, it shows:

addedFileName.pdf Page #

What if it were (for the 5th page of a 10-page added-file, for example):

addedFileName.pdf [5/10] Page #

?

Maybe it helps recognizing the added pages, maybe it doesn't. Or maybe the gui simply becomes too crowded.

[My inner desire is that you will drop the "Page" word in the second row anyway, so that it will look like evince thumbnails in its sidebar. But this is another story...]

3. I would like to suggest to make the newly added pages selected right after being added, so that the user can easily drag/move them inside the document.

Really nice job, Julian. :) I wish other people could give their feedbacks on how Slicer is progressing so far. I believe it's getting better and better from some objective point of view, but my opinion is biased since it's my opinion. 🤔

[junrrein]

1. What do you think about linking open-button and +-button? thinking This could be a cra*py idea, just wondering if it makes any sens.

It makes sense, and I think the result looks good. Let's keep this :+1:

2. Not fully sure that not showing the page number of the added file is good enough. Right now, at the bottom of added files, it shows:

addedFileName.pdf Page #

There was a bug in the previous screenshots: the page number displayed was supposed to be the "physical" number of that page in its original document, not the current position. It should have looked like this (the icon theme is not Adwaita):

Pay attention to how page numbers start again. Reordered pages also keep their page number under this model. Maybe this is even more confusing?

I do agree though, that recognizing which pages come from the original file, and which were "added", is not easy.

What if it were (for the 5th page of a 10-page added-file, for example):

addedFileName.pdf [5/10] Page #

?

Maybe it helps recognizing the added pages, maybe it doesn't. Or maybe the gui simply becomes too crowded.

So you suggest showing "filename + physical page number" on the first line, and "logical page number" on the second line?

A crazy idea that I came up with: what if "added" pages had a colored drop-shadow? this color would be different for different added documents, but the same color for pages coming from the same document. Pages coming from the original document would have no color.

[My inner desire is that you will drop the "Page" word in the second row anyway, so that it will look like evince thumbnails in its sidebar. But this is another story...]

This suggestion is not out of place. Let's see how it fits with the other ideas

1. I would like to suggest to make the newly added pages selected right after being added, so that the user can easily drag/move them inside the document.

Oh I forgot about this. I've moved it to another report: #93.

Really nice job, Julian. :) I wish other people could give their feedbacks on how Slicer is progressing so far. I believe it's getting better and better from some objective point of view, but my opinion is biased since it's my opinion. thinking

Having two heads thinking about this stuff is still infinitely better than one :)

[amivaleo]

Is the app subtitle capitalized correctly?

Not sure about this... I guess they shouldn't follow some particular rule, since they're not button labels, but explanation text. So maybe only the first word should be capitalized: "Multiple files added" and "Added file ...".

this is even more confusing?

I think it is. 🤔

So you suggest showing "filename + physical page number" on the first line, and "logical page number" on the second line?

Yes. What I don't like is that both rows uses the same style. Maybe one of the two should be brighter or should use italic text? 🤔 Something similar to what nautilus can do:

Except for the fact that the styles should be switched, so that the first row has some text style and/or different color, and the second row (the logical page number) is kept unchanged.

This could work nicely even if the "Page" string is removed and "filename + physical page number" is shown on the first line.

Having two heads thinking about this stuff is still infinitely better than one :)

💪

Just... Out of curiosity: how many steps are there between the moment in which you update the master branch and the moment in which such updates are delivered to everybody on their computer? Which of this steps you trigger?

[junrrein]

So you suggest showing "filename + physical page number" on the first line, and "logical page number" on the second line?

Yes. What I don't like is that both rows uses the same style. Maybe one of the two should be brighter or should use italic text? thinking Something similar to what nautilus can do:

Except for the fact that the styles should be switched, so that the first row has some text style and/or different color, and the second row (the logical page number) is kept unchanged.

This could work nicely even if the "Page" string is removed and "filename + physical page number" is shown on the first line.

I really like this idea. I think this will work nicely when there are multiple files open.

What about when there is only one file open and we reorder pages? If only the logical page number is shown, there would be no way to know what was the original position of a page. I'm not sure it matters that much though.

Just... Out of curiosity: how many steps are there between the moment in which you update the master branch and the moment in which such updates are delivered to everybody on their computer? Which of this steps you trigger?

Everytime I make a release, I upload that new version to Flathub. When do I make a new release? Everytime there is a new feature (however small), a bug fix, or updated translations. Release early, release often, as they say.

Currently, I want to ship the "add pages" feature, but I'm also waiting till I finish the stuff that's directly related to it (like what we are talking about in this report).

In a greater level of detail, this is the stuff I do before making a release:

• Update the translation templates (if applicable).
• Merge new/updated translations (if available).
• Update screenshots (if applicable).
• Add release notes.

[amivaleo]

What about when there is only one file open and we reorder pages? If only the logical page number is shown, there would be no way to know what was the original position of a page. I'm not sure it matters that much though.

Indeed, that's why the "added" string should contain the original page number:

addedFile.pdf [1/10]

4

Maybe it is better to preserve the position of the logical page number, so that it is always the first row. This solution would make Slicer closer to other apps (indeed: nautilus, for example) and maybe it's even easier to code since you should only add a row, instead of moving&adding rows.

A quick mockup:

[junrrein]

@amivaleo

Nice, I will go with this approach. Thanks a lot!

[amivaleo]

One more thing:

What if the original file pages never get a second row? I think this could make it easier for the user to distinguish the pages without the need to actually read the second row every time.

Of course IF the user adds several files, all of them have a second row, and of course the user has to pay more attention. But he would anyway, and yet again, not showing the second row for the original file still helps.

Furthermore: the original file is treated like some special file. But it is already, since its name is used as (first) title in the headerbar. It is ok to treat it in some special way. All in all, if the user undo enough times, he gets back to the original file only.

What I see as cons is:

• not all the elements in the grid are shown in the same way, some with a two-rows label, other with a single one.

And yet, this is exactly the purpose.

🤔

Give me your opinion. I'm hungry for feedbacks.

[junrrein]

What if the original file pages never get a second row? I think this could make it easier for the user to distinguish the pages without the need to actually read the second row every time.

The problem that I foresee is that, if we get rid of the second row, there won't be any indicator of the original page number for original file pages. I think there should be consistency here. Otherwise, I think the rest of your reasoning is valid.

So, I think these are the alternatives:

• We show physical page numbers. Then pages from the original file need a second row anyway.
• We don't show physical page numbers. Then we can omit a second row for pages from the original file.

[amivaleo]

there won't be any indicator of the original page number for original file pages

Oops! My bad. I completely forgot that! :D

Discard this latter suggestion then.

I go back to the previous idea:

• one single file loaded -> the title in the headerbar shows the file name + one single label at the bottom of every page only showing the (original) page numbering without any additional string.

• one single file loaded + one file is added -> the title in the headerbar gets a second row: the first one shows the original file name, while the second one shows "added file addedFileName.pdf" + every page label gets a second row (with a different color style) showing "fileName.pdf [5/10]": filename of every file currently open and its original page numbering + the first row keeps showing only the logical page numbering

• one single file is loaded + more than one file is added -> everything as the previous case with a single exception: the second row in the headerbar only shows "multiple files added"

Agree?

[junrrein]

• one single file loaded -> the title in the headerbar shows the file name + one single label at the bottom of every page only showing the (original) page numbering without any additional string.

With "(original) page numbering", do you mean logical or physical?

• one single file loaded + one file is added -> the title in the headerbar gets a second row: the first one shows the original file name, while the second one shows "added file addedFileName.pdf" + every page label gets a second row (with a different color style) showing "fileName.pdf [5/10]": filename of every file currently open and its original page numbering + the first row keeps showing only the logical page numbering

• one single file is loaded + more than one file is added -> everything as the previous case with a single exception: the second row in the headerbar only shows "multiple files added"

Agree?

I agree with the rest.

[amivaleo]

do you mean logical or physical?

I don't know the difference...

[junrrein]

@amivaleo

I was afraid that would be the case - those terms aren't really fitting anway.

Here's what I meant:

• Physical page number: The position the page has in the original file. This doesn't change when moving a page around, removing others, etc..
• Logical page number: The position the page currently has in Slicer's viewing area. This does change with the previously mentioned operations.

[amivaleo]

The physical one I'd say. 🤔

The fact is that... When another file is added, that number should indicate the logical page...

I need to think more about this, and to stay in front of my computer. I can't do any of both right now: I'm on bed, ready to sleep.

I'll write here again tomorrow (or "in 12 hours". I'm not really sure about what time of the day is there where you live).

[junrrein]

@amivaleo

Yeah, I think the meaning of the label should not change like that.

Don't worry, I'm not the speediest replier myself :) It's currently 17:34 where I live (Argentina). Rest well!

[amivaleo]

So...

I checked both pdfmodf and pdfshuffler: the former completely doesn't care about showing any page numbering, the latter does something interesting.

Shuffler put a question on me: is the logical page numbering really needed? 🤔

Let's think about this:

1- when the user loads the first file, logical and physical numbering coincides. If the physical page numbering is shown in the lable, after the user has shuffled all the pages, those numbers will be in some random order. And that's exactly what he wants to know: he wanted to put page X before page Y. It makes less sense to read the logical numbering: it doesn't give much information.

=> the physical page should be shown when one single file is loaded

2- when the user add another file (or even more than one), a second label appears at the bottom of every page, and so the use can recognize the original file of each page. There's more: he expects that the pages from the new file are loaded in order (from the first to the last), so he can still recognize every single page from the new file AND also those from the previously loaded file. If the labels shows the physical page (for each file), all of this "process of recognition" is simplified. If the labels show the logical numbering, no real information is given.

The only real help that could come from the logical numbering is knowing how many pages are loaded in total and the "absolute" position of each page.

I think that it's more common that users are interested in picking the right "physical" page and putting that after/before another the right "physical" page. In other words: "I want to the 3rd page of document A to stay after the 12th page of document B". It less common, I think, to have: "I want the 3rd page of document A to be the 13th page of the final document".

=> my conclusion is that the physical page numbering is the only one that should be shown. No need for logical numbering at all. The logical numbering has more sense in those apps where you actually read the pages (evince, okular, ...), because you want to know how many page you've already read and how many are still ahead. The purpose of Slicer is to shuffle page, rotate them, crop them (you will add this feature, don't you...? ^_^), etc. Slicer is somewhat the digital version of what we do with real documents: we (should) know the physical page of each document we have and when we put them in order, we think at "this page should go after this one, while that one should go before that other one" and so on. We think using the physical page numbering.

So, my suggestion after all this:

1. one file is loaded -> one single label showing the physical numbering.

2. more files are loaded -> one label showing the physical numbering + a second new row showing the filename of the document whom that page belongs to.

[amivaleo]

What happened to you Julian? We (I) need a new version of Slicer with the new features! :)

[junrrein]

@amivaleo

Sorry for the radio silence. I've been caught up with other stuff happening in my life, and I won't be spending time on Slicer for a while. Have a good day :)

[amivaleo]

@amivaleo

Sorry for the radio silence. I've been caught up with other stuff happening in my life, and I won't be spending time on Slicer for a while. Have a good day :)

Sorry, man. I hope everything is ok.

We'll see after a while then. :)

Take care. 💪

[junrrein]

@amivaleo

I basically agree with the last comments you made, with the only difference being that when a file is added, I show the filename above the page number. I prefer it this way, since I think knowing the file a page comes from is the first diferentiation.

This is already in master, and a release will happen in a short while. Thanks for the input!