Re: [Lxde-list] RFD: where 'Find Files...' menu option should be?

[Stephan Sokolow <gmane.ssokolow@sp...>]

Keep it under Tools. That's the best place for it.

In traditional applications, both "File" and "Edit" refer to the current 
document, which means that, in a file manager, "Edit" is expected to 
apply to the selected files and as a way to make Ctrl+F "find in current 
folder only" search discoverable via the GUI.

(Which is why I think it's incredibly stupid of the GNOME devs to try to 
convince everyone to put application-wide Preferences there. They're 
letting the literal meaning of the menu's title blind them to the 
underlying concept which it's supposed to represent.)

As for the File menu, that's for creating/opening/closing documents (in 
the case of a file manager, tabs, windows, or blank files). Putting a 
search function in there makes about as much sense as putting it under 
View because you want to "View" the results of your search or putting it 
under "Go" because you'll probably want to go to one of the results 
after you find it.

If it's the sparseness of the Tools menu that you're concerned about, 
why not allow users to add custom entries to it?

On 13-12-30 10:39 AM, Andrej N. Gritsenko wrote:
>      Hello!
>
>      What do you think, where "Find Files..." belongs to - the File menu
> or the Edit menu? Search usually is in Edit menu but search in pcmanfm
> opens new window/tab with search results so probably it should be in the
> File menu instead? I would like to know your opinions on that.
>
>      Thanks in advance.
>      Andriy.
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
>

Re: [Lxde-list] RFD: where 'Find Files...' menu option should be?

[Stephan Sokolow <gmane.ssokolow@sp...>]

Keep it under Tools. That's the best place for it.

In traditional applications, both "File" and "Edit" refer to the current 
document, which means that, in a file manager, "Edit" is expected to 
apply to the selected files and as a way to make Ctrl+F "find in current 
folder only" search discoverable via the GUI.

(Which is why I think it's incredibly stupid of the GNOME devs to try to 
convince everyone to put application-wide Preferences there. They're 
letting the literal meaning of the menu's title blind them to the 
underlying concept which it's supposed to represent.)

As for the File menu, that's for creating/opening/closing documents (in 
the case of a file manager, tabs, windows, or blank files). Putting a 
search function in there makes about as much sense as putting it under 
View because you want to "View" the results of your search or putting it 
under "Go" because you'll probably want to go to one of the results 
after you find it.

If it's the sparseness of the Tools menu that you're concerned about, 
why not allow users to add custom entries to it?

On 13-12-30 10:39 AM, Andrej N. Gritsenko wrote:
>      Hello!
>
>      What do you think, where "Find Files..." belongs to - the File menu
> or the Edit menu? Search usually is in Edit menu but search in pcmanfm
> opens new window/tab with search results so probably it should be in the
> File menu instead? I would like to know your opinions on that.
>
>      Thanks in advance.
>      Andriy.
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
>

Re: [Lxde-list] RFD: where 'Find Files...' menu option should be?

[Andrej N. Gritsenko <andrej@re...>]

    Hello!

Sérgio Marques has written on Monday, 30 December, at 17:34:
>2013/12/30 Stephan Sokolow <gmane.ssokolow@...>

>> Keep it under Tools. That's the best place for it.

    All of HIG require that any menu should contain 3 items or more, and
only exception is a Help menu. We got only 2 options for Tools:
 - Open Current Folder in Terminal
 - Find Files...

And since 'Open Current Folder in Terminal' matches File menu very well,
we got only one stray option under Tools menu, and that case (1 option)
is denied, it's why we should move it to other menu.

    Also speaking of other file managers - Dolphin has built-in advanced
search and it has it under Edit menu, it's why I think it might belong
there. Neither Nautilus nor Thunar have any kind of advanced search.

>Better choice than mine.

>I agree with this one.

>> In traditional applications, both "File" and "Edit" refer to the current
>> document, which means that, in a file manager, "Edit" is expected to
>> apply to the selected files and as a way to make Ctrl+F "find in current
>> folder only" search discoverable via the GUI.

>> (Which is why I think it's incredibly stupid of the GNOME devs to try to
>> convince everyone to put application-wide Preferences there. They're
>> letting the literal meaning of the menu's title blind them to the
>> underlying concept which it's supposed to represent.)

>> As for the File menu, that's for creating/opening/closing documents (in
>> the case of a file manager, tabs, windows, or blank files). Putting a
>> search function in there makes about as much sense as putting it under
>> View because you want to "View" the results of your search or putting it
>> under "Go" because you'll probably want to go to one of the results
>> after you find it.

>> If it's the sparseness of the Tools menu that you're concerned about,
>> why not allow users to add custom entries to it?

    Well, you probably mean support for placing user-defined actions on
the toolbar so you advice to have mirror of toolbar in the Tools menu. It
might be OK if we already supported toolbar extension but we currently
support only context menu, and toolbar wouldn't be available in 1.2 yet,
we've placed a deadline for 1.2. So (at least for now) we have to put the
'Find Files...' into some other menu. I'm sorry.

>> On 13-12-30 10:39 AM, Andrej N. Gritsenko wrote:
>> >      What do you think, where "Find Files..." belongs to - the File menu
>> > or the Edit menu? Search usually is in Edit menu but search in pcmanfm
>> > opens new window/tab with search results so probably it should be in the
>> > File menu instead? I would like to know your opinions on that.

    With best regards.
    Andriy.

Re: [Lxde-list] RFD: where 'Find Files...' menu option should be?

[Andrej N. Gritsenko <andrej@re...>]

    Hello!

Stephan Sokolow has written on Monday, 30 December, at 20:24:
>To be honest, it really sounds like you're sticking to the HIG too rigidly.

>I think causing menu items to move around unexpectedly from version to 
>version is a bigger design evil than letting a minor HIG violation 
>through for one version.

Well, only one item that is moved is 'Open Current Folder in Terminal'.
The 'Find Files...' is very new item which was in Tools only one version
so I see no much harm to move it anywhere. But well, if you think it is
very bad when menu items are moved then we can let Tools stay still.

>If it really bothers you so much, would it be possible to put off the 
>removal of "Open Current Folder as Root" for one more release?

That thing brings more problems than it solves so it's better to be an
user-defined thing as we discussed it earlier. And there is already a
detailed description at the Wiki you know.

    Cheers!
    Andriy.

Re: [Lxde-list] RFD: where 'Find Files...' menu option should be?

[Stephan Sokolow <gmane.ssokolow@sp...>]

On 13-12-31 05:18 AM, Andrej N. Gritsenko wrote:
>      Hello!
>
> Stephan Sokolow has written on Monday, 30 December, at 20:24:
>> To be honest, it really sounds like you're sticking to the HIG too rigidly.
>
>> I think causing menu items to move around unexpectedly from version to
>> version is a bigger design evil than letting a minor HIG violation
>> through for one version.
>
> Well, only one item that is moved is 'Open Current Folder in Terminal'.
> The 'Find Files...' is very new item which was in Tools only one version
> so I see no much harm to move it anywhere. But well, if you think it is
> very bad when menu items are moved then we can let Tools stay still.

Think about it like this: There are different classes of problems.

Causing confusion is a worse class of problem than ugliness.

1. Moving menu items causes confusion for each existing user of that 
feature who upgrades. Moving menu items twice causes twice as much 
confusion.
2. Putting a menu item in a less intuitive location causes confusion for 
each user who wants to start using that feature and isn't familiar with 
its location.
3. Leaving a menu item with too few entries for a version or two just 
causes temporary ugliness and nowhere near the worst kind of it. (You 
only see it if you open the menu, it still follows the rest of the HIG, 
etc.)

>
>> If it really bothers you so much, would it be possible to put off the
>> removal of "Open Current Folder as Root" for one more release?
>
> That thing brings more problems than it solves so it's better to be an
> user-defined thing as we discussed it earlier. And there is already a
> detailed description at the Wiki you know.
>
>      Cheers!
>      Andriy.
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
>

Re: [Lxde-list] RFD: where 'Find Files...' menu option should be?

[Stephan Sokolow <gmane.ssokolow@sp...>]

To be honest, it really sounds like you're sticking to the HIG too rigidly.

I think causing menu items to move around unexpectedly from version to 
version is a bigger design evil than letting a minor HIG violation 
through for one version.

If it really bothers you so much, would it be possible to put off the 
removal of "Open Current Folder as Root" for one more release?

On 13-12-30 01:31 PM, Andrej N. Gritsenko wrote:
>      Hello!
>
> Sérgio Marques has written on Monday, 30 December, at 17:34:
>> 2013/12/30 Stephan Sokolow <gmane.ssokolow@...>
>
>>> Keep it under Tools. That's the best place for it.
>
>      All of HIG require that any menu should contain 3 items or more, and
> only exception is a Help menu. We got only 2 options for Tools:
>   - Open Current Folder in Terminal
>   - Find Files...
>
> And since 'Open Current Folder in Terminal' matches File menu very well,
> we got only one stray option under Tools menu, and that case (1 option)
> is denied, it's why we should move it to other menu.
>
>      Also speaking of other file managers - Dolphin has built-in advanced
> search and it has it under Edit menu, it's why I think it might belong
> there. Neither Nautilus nor Thunar have any kind of advanced search.
>
>> Better choice than mine.
>
>> I agree with this one.
>
>>> In traditional applications, both "File" and "Edit" refer to the current
>>> document, which means that, in a file manager, "Edit" is expected to
>>> apply to the selected files and as a way to make Ctrl+F "find in current
>>> folder only" search discoverable via the GUI.
>
>>> (Which is why I think it's incredibly stupid of the GNOME devs to try to
>>> convince everyone to put application-wide Preferences there. They're
>>> letting the literal meaning of the menu's title blind them to the
>>> underlying concept which it's supposed to represent.)
>
>>> As for the File menu, that's for creating/opening/closing documents (in
>>> the case of a file manager, tabs, windows, or blank files). Putting a
>>> search function in there makes about as much sense as putting it under
>>> View because you want to "View" the results of your search or putting it
>>> under "Go" because you'll probably want to go to one of the results
>>> after you find it.
>
>>> If it's the sparseness of the Tools menu that you're concerned about,
>>> why not allow users to add custom entries to it?
>
>      Well, you probably mean support for placing user-defined actions on
> the toolbar so you advice to have mirror of toolbar in the Tools menu. It
> might be OK if we already supported toolbar extension but we currently
> support only context menu, and toolbar wouldn't be available in 1.2 yet,
> we've placed a deadline for 1.2. So (at least for now) we have to put the
> 'Find Files...' into some other menu. I'm sorry.
>
>>> On 13-12-30 10:39 AM, Andrej N. Gritsenko wrote:
>>>>       What do you think, where "Find Files..." belongs to - the File menu
>>>> or the Edit menu? Search usually is in Edit menu but search in pcmanfm
>>>> opens new window/tab with search results so probably it should be in the
>>>> File menu instead? I would like to know your opinions on that.
>
>      With best regards.
>      Andriy.
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> Lxde-list mailing list
> Lxde-list@...
> https://lists.sourceforge.net/lists/listinfo/lxde-list
>

Re: [Lxde-list] RFD: where 'Find Files...' menu option should be?

[PCMan <pcman.tw@gm...>]

On Tue, Dec 31, 2013 at 2:31 AM, Andrej N. Gritsenko <andrej@...>wrote:

>     Hello!
>
> Sérgio Marques has written on Monday, 30 December, at 17:34:
> >2013/12/30 Stephan Sokolow <gmane.ssokolow@...>
>
> >> Keep it under Tools. That's the best place for it.
>
>     All of HIG require that any menu should contain 3 items or more, and
> only exception is a Help menu. We got only 2 options for Tools:
>  - Open Current Folder in Terminal
>  - Find Files...
>
> And since 'Open Current Folder in Terminal' matches File menu very well,
> we got only one stray option under Tools menu, and that case (1 option)
> is denied, it's why we should move it to other menu.
>
>     Also speaking of other file managers - Dolphin has built-in advanced
> search and it has it under Edit menu, it's why I think it might belong
> there. Neither Nautilus nor Thunar have any kind of advanced search.
>
> >Better choice than mine.
>
> >I agree with this one.
>
> >> In traditional applications, both "File" and "Edit" refer to the current
> >> document, which means that, in a file manager, "Edit" is expected to
> >> apply to the selected files and as a way to make Ctrl+F "find in current
> >> folder only" search discoverable via the GUI.
>
> >> (Which is why I think it's incredibly stupid of the GNOME devs to try to
> >> convince everyone to put application-wide Preferences there. They're
> >> letting the literal meaning of the menu's title blind them to the
> >> underlying concept which it's supposed to represent.)
>
> >> As for the File menu, that's for creating/opening/closing documents (in
> >> the case of a file manager, tabs, windows, or blank files). Putting a
> >> search function in there makes about as much sense as putting it under
> >> View because you want to "View" the results of your search or putting it
> >> under "Go" because you'll probably want to go to one of the results
> >> after you find it.
>
> >> If it's the sparseness of the Tools menu that you're concerned about,
> >> why not allow users to add custom entries to it?
>
>     Well, you probably mean support for placing user-defined actions on
> the toolbar so you advice to have mirror of toolbar in the Tools menu. It
> might be OK if we already supported toolbar extension but we currently
> support only context menu, and toolbar wouldn't be available in 1.2 yet,
> we've placed a deadline for 1.2. So (at least for now) we have to put the
> 'Find Files...' into some other menu. I'm sorry.
>
> >> On 13-12-30 10:39 AM, Andrej N. Gritsenko wrote:
> >> >      What do you think, where "Find Files..." belongs to - the File
> menu
> >> > or the Edit menu? Search usually is in Edit menu but search in pcmanfm
> >> > opens new window/tab with search results so probably it should be in
> the
> >> > File menu instead? I would like to know your opinions on that.
>
>     With best regards.
>     Andriy.
>
>
I forgot to tell you.
In my original plan, I'd like to add more tools under the Tools menu.
Due to limited time, I haven't do it.
Actually it's even possible to make the Tools menu extesible so people can
extend that menu with some config files, such as via the DES-EMA spec.
So, I strongly suggest keeping that menu and avoid moving menu items during
version upgrades.
There will be more than 3 items in the future.

Re: [Lxde-list] RFD: where 'Find Files...' menu option should be?

[Andrej N. Gritsenko <andrej@re...>]

    Hello!

PCMan has written on Wednesday,  8 January, at  0:13:
>I forgot to tell you.
>In my original plan, I'd like to add more tools under the Tools menu.
>Due to limited time, I haven't do it.

    Well, I've added one more there already due to FR report. :)

>Actually it's even possible to make the Tools menu extesible so people can
>extend that menu with some config files, such as via the DES-EMA spec.

    Yes, I know, DES-EMA spec allows to add tools into the Toolbar. We
don't have such support in the PCManFM yet but I believe we will have it
later therefore we can add them into the Tools menu.

>So, I strongly suggest keeping that menu and avoid moving menu items during
>version upgrades.

    After the discussion here I've fixed my mistake and returned them
back where they were. Thank you very much!

>There will be more than 3 items in the future.

    Cheers!
    Andriy.

Re: [Lxde-list] RFD: where 'Find Files...' menu option should be?

[Sérgio Marques <smarquespt@gm...>]

2013/12/30 Stephan Sokolow <gmane.ssokolow@...>

> Keep it under Tools. That's the best place for it.
>


Better choice than mine.

I agree with this one.

Regards



>
> In traditional applications, both "File" and "Edit" refer to the current
> document, which means that, in a file manager, "Edit" is expected to
> apply to the selected files and as a way to make Ctrl+F "find in current
> folder only" search discoverable via the GUI.
>
> (Which is why I think it's incredibly stupid of the GNOME devs to try to
> convince everyone to put application-wide Preferences there. They're
> letting the literal meaning of the menu's title blind them to the
> underlying concept which it's supposed to represent.)
>
> As for the File menu, that's for creating/opening/closing documents (in
> the case of a file manager, tabs, windows, or blank files). Putting a
> search function in there makes about as much sense as putting it under
> View because you want to "View" the results of your search or putting it
> under "Go" because you'll probably want to go to one of the results
> after you find it.
>
> If it's the sparseness of the Tools menu that you're concerned about,
> why not allow users to add custom entries to it?
>
> On 13-12-30 10:39 AM, Andrej N. Gritsenko wrote:
> >      Hello!
> >
> >      What do you think, where "Find Files..." belongs to - the File menu
> > or the Edit menu? Search usually is in Edit menu but search in pcmanfm
> > opens new window/tab with search results so probably it should be in the
> > File menu instead? I would like to know your opinions on that.
> >
> >      Thanks in advance.
> >      Andriy.
> >
> >
> ------------------------------------------------------------------------------
> > Rapidly troubleshoot problems before they affect your business. Most IT
> > organizations don't have a clear picture of how application performance
> > affects their revenue. With AppDynamics, you get 100% visibility into
> your
> > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
> AppDynamics Pro!
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> >
>
>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> Lxde-list mailing list
> Lxde-list@...
> https://lists.sourceforge.net/lists/listinfo/lxde-list
>



-- 
Sérgio Marques

Re: [Lxde-list] RFD: where 'Find Files...' menu option should be?

[Stephan Sokolow <gmane.ssokolow@sp...>]

On 13-12-30 11:29 AM, Stephan Sokolow wrote:
> In traditional applications, both "File" and "Edit" refer to the current
> document

I should probably clarify this slightly. Here are the classic "original" 
menus, in their original order, and with their original meanings:

File - Operations which change the meaning of "current document" 
(new/open/close) or, in something which operates on an in-memory working 
copy, operations which cause interaction with other media/devices 
(open/save/print/send to iPod/etc.)

Edit - Operations which operate on the contents of the "current 
document". In traditional applications, everything in this menu operates 
exclusively on the in-memory working copy until saved/printed/exported/etc.

View - Operations which alter the way in which the application presents 
its UI and the "current document" contents. (toolbar controls, view 
mode, etc.)

[Additional menus would be added here in the sequence]

Tools (or, sometimes, "Options") - This is where you put "embedded 
utilities" like spell-checking and the application's preferences panel 
and integration for external utilities.

Window - All functionality necessary to implement workarounds for weak 
window management in an application with an MDI (Multiple Document 
Interface)-based GUI like Word or Photoshop. (In other words, 
proprietary shortcuts for opening, closing, and navigating between 
windows within a single application)

Help - All documentation and related "help" functionality other than 
tooltips. Online manual, release notes, about dialog, license, credits, 
feedback dialog, "enter troubleshooting mode" trigger, "enter context 
help mode" trigger, etc.

>
> (Which is why I think it's incredibly stupid of the GNOME devs to try to
> convince everyone to put application-wide Preferences there. They're
> letting the literal meaning of the menu's title blind them to the
> underlying concept which it's supposed to represent.)
>
> As for the File menu, that's for creating/opening/closing documents (in
> the case of a file manager, tabs, windows, or blank files). Putting a
> search function in there makes about as much sense as putting it under
> View because you want to "View" the results of your search or putting it
> under "Go" because you'll probably want to go to one of the results
> after you find it.
>
> If it's the sparseness of the Tools menu that you're concerned about,
> why not allow users to add custom entries to it?
>
> On 13-12-30 10:39 AM, Andrej N. Gritsenko wrote:
>>       Hello!
>>
>>       What do you think, where "Find Files..." belongs to - the File menu
>> or the Edit menu? Search usually is in Edit menu but search in pcmanfm
>> opens new window/tab with search results so probably it should be in the
>> File menu instead? I would like to know your opinions on that.
>>
>>       Thanks in advance.
>>       Andriy.
>>
>> ------------------------------------------------------------------------------
>> Rapidly troubleshoot problems before they affect your business. Most IT
>> organizations don't have a clear picture of how application performance
>> affects their revenue. With AppDynamics, you get 100% visibility into your
>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
>> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
>>
>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
>