Re: Meld 1.8.1 released



The flag idea may be ok. Could it be possible to start python.exe with
a hidden console?

Cheers,

Angel


On Sun, Sep 29, 2013 at 6:39 PM, Keegan Witt <keeganwitt gmail com> wrote:
I think it's because they're not Python apps.  The problem is if you call
Meld with pythonw.exe (which hides the command prompt), it doesn't wait for
the process to end before returning an exit code.  The only way I've seen to
get an exit code is by calling with python.exe, which will create a command
prompt window.  Another idea I had to avoid having 2 wrappers is to have the
first argument to the wrapper be some special maker to tell it to use
python.exe (and let the default be pythonw.exe), and have it eat that arg
before starting Meld with the rest of the args.  Opinions?

-Keegan


On Sat, Sep 28, 2013 at 4:10 AM, Angel Ezquerra <angel ezquerra gmail com>
wrote:

That is a good point, but personally I would hate even more to get a
command prompt every time I open the diff tool.

Version Control Tools use diff such as meld for two things: diffing
and merging. I don't think that tools usually need the exit code when
using meld for diffing. For merging it would be nice to get the exit
code though. Currently TortoiseHg will simply ask the user if the
merge was successful, but with other tools this is not necessary.

I don't quite understand why other tools (e.g. KDiff3, WinMerge) do
not have this problem. These are GUI tools but they can keep
TortoiseHg (or whoever calls the tool) waiting for the exit code until
they are done, but they do not show a command prompt. Is this a
fundamental problem in how meld is wrapped on windows?

Cheers,

Angel



On Tue, Sep 24, 2013 at 4:10 PM, Keegan Witt <keeganwitt gmail com> wrote:
That's true, but wouldn't you want tools like that to be aware of when
the
merging process has ended?  If I call pythonw, it will appear to the
tool
calling the process that the process ended immediately.  This also means
the
status code returned by pythonw is worthless since it will always be 0.
Isn't that an issue for these tools as well?  Sorry for my ignorance, I
don't use Meld for that.

I agree that it stinks that a separate window will now be opened, but
otherwise the calling process loses information about the status of the
process it called.  I was thinking too of how this might be in a script
that
helps a user do some larger workflow.  If it exits immediately (and/or
with
a worthless status code), the script wouldn't know whether to proceed or
not
with the next steps.

-Keegan


On Tue, Sep 24, 2013 at 9:24 AM, Angel Ezquerra
<angel ezquerra gmail com>
wrote:

Hi,

personally I think this change (calling python.exe rather than
pythonw.exe) will be a serious regression when using meld with a tool
such as TortoiseHg. TortoiseHg _always_ calls meld with parameters.
This means that every time that you would use meld to diff or merge
files from TortoiseHg (or any similar tool) you'd see a prompt window
appear.

Cheers,

Angel



On Tue, Sep 24, 2013 at 10:35 AM, Keegan Witt <keeganwitt gmail com>
wrote:
Sorry for the delay.  Someone reported that GTK wouldn't load for him
and I
was hoping to track that down why before updating the binaries.  I
haven't
figured it out (it doesn't help that I've not been able to recreate
the
issue), but I've decided to go ahead and release new ones in the mean
time.
Has anyone else experienced this issue?  Have an suggestions?  I've
already
tried having him clear his path before calling the Python from
Portable
Python with the absolute paths (which didn't help), though he is able
to
run
the GTK demo.

Besides the update to 1.8.1, I also now call python.exe instead of
pythonw.exe when calling meld.exe with parameters.  This allows you
to
call
Meld from the commandline without pythonw exiting right away (the
only
downside being that a dialog box for python appears in that case --
not
sure
there's really a way around this).  When calling without parameters
(for
example from shortcuts), it continues to call pythonw.  The issue
list
for
this installer release can be seen here.

-Keegan


On Sat, Sep 21, 2013 at 7:08 PM, Kai Willadsen
<kai willadsen gmail com>
wrote:

Meld 1.8.1 has been released.


  Fixes:

    * Add AppData file (Kai Willadsen)
    * Change order of version control selection for CVS and old SVN
(Kai
      Willadsen)
    * Fix escaped markup in folder comparisons (Kai Willadsen)

  Translations:

    * Daniel Mustieles (es)
    * Enrico Nicoletto (pt_BR)
    * Gabor Kelemen (hu)
    * Marek Černocký (cs)
    * Milo Casagrande (it)
    * Piotr Drąg (pl)


This release can be downloaded from:

http://download.gnome.org/sources/meld/1.8/meld-1.8.1.tar.xz


What is Meld?
-------------

Meld is a visual diff and merge tool. It lets you compare two or
three
files,
and updates the comparisons while you edit them in-place. You can
also
compare
folders, launching comparisons of individual files as desired. Last
but
by
no
means least, Meld lets you work with your current changes in a wide
variety of
version control systems, including Git, Bazaar, Mercurial,
Subversion
and
CVS.
_______________________________________________
meld-list mailing list
meld-list gnome org
https://mail.gnome.org/mailman/listinfo/meld-list



_______________________________________________
meld-list mailing list
meld-list gnome org
https://mail.gnome.org/mailman/listinfo/meld-list






[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]