Re: Launch* functions moved

Oliver,

thanks for the details explanation. I can see what the idea behind the 
scheme is, [but unless the applications implement those verbs properly 
and consistently, IMHO, it creates more confusion than use...]

Anyway, personally, I'd opt for any kind of consistent, predictive 
behavior when double clicking a file, even if it may not be what the 
user wants. I don't know whether Explorer's behavior is predictive in 
that respect, but at least that's what all users are used to...
How about trying "edit" first and then "open"? This seems like a good 
mixture for a double click approach that might do kind of what users 
expect...

I think the idea about the context menu submenu is actually the best 
approach - together with a consistent double click behavior.

Or maybe I just shouldn't get involved here, since I might have no clue 
what I'm talking about ;-)


Am 05.02.2004 um 17:05 schrieb Oliver Giesen:

>> Not being a Windows person myself: Could you shed some light on what
>> the difference between "Open" and "Edit" is?
>
> This was discussed at length before when I started implementing this.
> "Open" as it is currently used in WinCvs corresponds mostly to what 
> would
> happen if you double-click a file in Explorer. However, this is often 
> not what
> you want when working in in a version control system, e.g. you really 
> don't
> want scripts to be executed or HTML pages to be opened in a browser. 
> Instead
> you usually want to open them in an appropriate editor. For the two 
> examples
> given it is of course usually OK to just use the default editor as 
> specified
> in the WinCvs preferences but even there it's often more convenient to 
> open
> them in a specialized editor application. Also, what about images? 
> Usually the
> default double-click behaviour is to open them in some kind of 
> view-only
> application (e.g. a web-browser), while again, when working in WinCvs, 
> what you
> usually want to do is to edit them instead.
>
> Windows itself offers so called "verbs" to be executed on defined file
> types. Any application that can handle files of a specific type 
> usually registers
> an "open" verb on installation. Some applications also register a 
> dedicated
> "edit" verb (e.g. PythonWin) to make the distinction between 
> viewing/executing
> (aka opening) a file vs. editing it. These non-default (i.e.
> non-double-click) verbs are available from the context menu when 
> right-clicking a file in
> Explorer.
>
> The change I implemeted harnesses this OS mechanism by exposing both
> possiblities in the GUI. So far so good. However, we also decided to 
> change the
> double-click behaviour accordingly. The downside is that far too many
> applications do NOT register an "edit" association by default (but 
> often an "open"
> association instead) which has the effect that after upgrading to 
> WinCvs 1.3.15
> double-clicking a file often no longer opens it in its associated 
> application
> but in the WinCvs default viewer instead (as that is the fallback when 
> no
> "edit" association could be found). I still think that if you know 
> about this
> mechanism and know how to use it this is a more than acceptable change 
> and
> setting up new "edit" associations is a one-time operation (I even 
> supplied a
> macro to ease this) but all that's currently in the release notes 
> about this is:
> "Provide additional view and edit commands to fully utilize shell 
> opening
> and editing files options (Shell Actions)".
>
>
> On hindsight (yes, I know it's a bit late for it really :( ), how 
> about this
> slightly different approach:
>
> 1. Change default behaviour back to mimicking Explorer, i.e. 
> double-clicking
> executes the default action as defined by the shell (whatever it is, 
> "open",
> "edit", "editwithsyn", etc.).
>
> 2. Expose all available verbs in the WinCvs GUI by means of a 
> dynamically
> built context-submenu. This should be relatively easy. You just have to
> enumerate entries of a certain registry key associated with the file 
> type, there's
> probably an API for it already.
>
> 3. Offer an option to override the shell default double-click action 
> for
> WinCvs only. This would create a WinCvs specific verb for the file 
> type in
> question (e.g. "wincvsedit"). When double-clicking a file, we will 
> first try to
> execute this verb, if that fails, we go for the default action (see 
> 1.). In
> order not to clutter the Explorer context-menu with WinCvs-specific 
> entries we
> would flag the created verb as "Extended" which would have the effect 
> that it
> will only show up in Explorer when holding down the shift key while 
> invoking
> the context menu.
>
> It wouldn't really invalidate any of the work already done but it would
> involve messing with the registry which Jerzy, as I understood, 
> preferred to
> leave to my macros... ;)
>
>
>> I don't quite see whether it really makes life easier for users...
>
> It definitely could. I'm quite happy with it myself as I no longer 
> have to
> drag and drop files from WinCvs to my editor applications but I could 
> just as
> well understand why others complain... E.g. most C++ IDEs (e.g. BCB, 
> VS) only
> register an "open" association instead of an "edit" association...
>
>
>> Yes, you anticipated this correctly.
>> A not-so-smart spam filter that _considers_ itself very smart is
>> sometimes worse than the spam by itself... ;-)
>
> Do you happen to be a list moderator? Could someone turn this off for
> cvsgui-dev too, please?
> I'm sending this one through the GMX web interface in the hopes that
> SpamGuard likes the headers better this way...

Sorry, no, I'm not a moderator, but either somebody turned off the spam 
check or the web interface is in fact more acceptable - at least this 
mail did come through...

</jum>



------------------------ Yahoo! Groups Sponsor ---------------------~-->
Upgrade to 128-bit SSL Security!
http://us.click.yahoo.com/qZ0LdD/yjVHAA/TtwFAA/NhFolB/TM
---------------------------------------------------------------------~->

 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
     http://groups.yahoo.com/group/cvsgui-dev/

<*> To unsubscribe from this group, send an email to:
     [email protected]

<*> Your use of Yahoo! Groups is subject to:
     http://docs.yahoo.com/info/terms/