combine page move & rename features for simpler-yet-increased functionality

I'm open to the idea, but looking for a bit more design on the input fields for the old and new page names.

As a user:
- If I want to do move (not rename) I want to have autocomplete of existing pages
- If I do rename and my parent path is very long, I want the basename focussed without going into the text field where the end is maybe out of view and manually select basename and edit

Both of these user scenarios are kind of addressed with the current two dialogs

For the old name, we can just use an entry that completes the page, no need to distinguish path and name
For the new name we should have to input elements - these could be two entries, but would love a way to represent that on a single line without it looking messy.

Maybe file dialogs can offer some inspriration?

Hmm... yes, I'm not sure I fully considered those points originally.

Some more thoughts:
- I agree that autocomplete and parsing *would* be far easier to implement if the new dirname and new basename were in separate fields... and possibly easier for the user to understand.
- IMO... the functional aspect (i.e. of two fields & beign able to perform a move-and-rename) is far more important than the aesthetics of having the two fields be on the same line... with a varying dialog size (which gtk seems to always make too small anyway) I don't think it's worth the engineering effort. Give me two bland and oversized 90's-era entry fields any day!
- We could keep the two entry points (move & rename), with only slightly modified behaviour (which field to initially focus; the page's basename or dirname).
- If using only on field for the new name/path, and the user specifies an existing page (as autocomplete would make easy), I think that could be assumed as only the new dirname... making it a classic move operation (same basename).

I'm attaching a revised mockup.

Thanks for the new mock-up. I think you are right, combining in a single
dialog is an improvement already. Better widgets is a next step that can be
independent.

-- Jaap

On Thu, Apr 13, 2017 at 4:41 PM Robert <email address hidden> wrote:

> Hmm... yes, I'm not sure I fully considered those points originally.
>
> Some more thoughts:
> - I agree that autocomplete and parsing *would* be far easier to implement
> if the new dirname and new basename were in separate fields... and possibly
> easier for the user to understand.
> - IMO... the functional aspect (i.e. of two fields & beign able to perform
> a move-and-rename) is far more important than the aesthetics of having the
> two fields be on the same line... with a varying dialog size (which gtk
> seems to always make too small anyway) I don't think it's worth the
> engineering effort. Give me two bland and oversized 90's-era entry fields
> any day!
> - We could keep the two entry points (move & rename), with only slightly
> modified behaviour (which field to initially focus; the page's basename or
> dirname).
> - If using only on field for the new name/path, and the user specifies an
> existing page (as autocomplete would make easy), I think that could be
> assumed as only the new dirname... making it a classic move operation (same
> basename).
>
> I'm attaching a revised mockup.
>
>
> ** Attachment added: "Zim-Better-PageMoveByRename-58ef8b49.png"
>
> https://bugs.launchpad.net/zim/+bug/1674785/+attachment/4861311/+files/Zim-Better-PageMoveByRename-58ef8b49.png
>
> --
> You received this bug notification because you are subscribed to Zim.
> https://bugs.launchpad.net/bugs/1674785
>
> Title:
> combine page move & rename features for simpler-yet-increased
> functionality
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/zim/+bug/1674785/+subscriptions
>