Zim

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

Bug #1674785 reported by Robert
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Zim
Confirmed
Wishlist
Unassigned

Bug Description

I find quite frequently that I need to change both the path and the name of a page, and that this is "harder than it should be" in zim.

At the moment, this workflow is approximately:
1. judge which of its present or target directories has fewer entries (because it will "get lost")
2. Usually, *move* the page first
3. Restart zim to avoid the index pane bugging out
4. Go hunt out the page I just moved
5. Rename the page
6. If it had any sub-pages, restart zim again.

I know it's made worse by the workarounds, but ideally this could be simplified to a single dialog (and one restart). Mockup attached.

Revision history for this message
Robert (pv-ubuntuone) wrote :
Revision history for this message
Jaap Karssenberg (jaap.karssenberg) wrote :

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?

Revision history for this message
Robert (pv-ubuntuone) 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.

Revision history for this message
Jaap Karssenberg (jaap.karssenberg) wrote : Re: [Bug 1674785] Re: combine page move & rename features for simpler-yet-increased functionality

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
>

Changed in zim:
status: New → Confirmed
importance: Undecided → Wishlist
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.