RE: Launch* functions moved

> 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...

Cheers,

Oliver
----	------------------
JID:	[email protected]
ICQ:	18777742	(http://wwp.icq.com/18777742)

-- 
GMX ProMail (250 MB Mailbox, 50 FreeSMS, Virenschutz, 2,99 EUR/Monat...)
jetzt 3 Monate GRATIS + 3x DER SPIEGEL +++ http://www.gmx.net/derspiegel +++



 
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/