Ian,
Your patch is working, the new node is selected after rename as it is
expected now.
While testing your patch I found yet another bug in the project manager
(most likely unrelated to this patch), I'll report it later.
Thank you for your kind words.
Best regards,
Mikołaj Wielgus
On Sun,
Ok, I have pushed the fixes for the rename tree update, and an attempt to
fix the item selection after rename. Since Gtk uses the rename event, I
can't test the add code path easily (it is probably time I actually tried
to set up my mac and Windows build environments). It would be good to
verify
I've tested Ian's patch on Windows 10 and it works correctly for me, with
exception to the same selection problem, as well.
I've done simple logging and found out that the rename event routine is not
executed during rename, but the delete and create event routines are, in
this order.
Thanks for testing. I had noticed the selection issue on GTK as well, so I
will fix it up before I push it.
The file system watcher is a finiky creature. GTK for sure uses the rename
events (I traced those through the logic last night), but according to the
docs
How bizarre. Make you wonder how it worked on Mac and Windows. (Hmmm… I
wonder if GTK goes through wxFSW_EVENT_RENAME and Mac and Windows go through
wxFSW_EVENT_DELETE and wxFSW_EVENT_CREATE?)
Your patch works on OSX except for one thing: it doesn’t get the selection
right (selecting the
Ok, so I dug into this some more and first of all, the changes that Jeff
pushed still didn't work on GTK.
The root cause of this doesn't appear to be our file system watcher, but
was instead the fact that the tree was being improperly updated. First of
all, we were renaming the old node with the
Jeff,
your new version appears to be working well on my computer on Windows.
Best regards,
Mikołaj Wielgus
On Sat, Nov 16, 2019 at 1:02 AM Jeff Young wrote:
> I pushed a smarter version of my original fix. @Mikolaj & @Ian if you
> could test it on Windows and GTK that would be great.
>
>
I pushed a smarter version of my original fix. @Mikolaj & @Ian if you could
test it on Windows and GTK that would be great.
Cheers,
Jeff.
> On 15 Nov 2019, at 22:27, Ian McInerney wrote:
>
> Scratch my last. It is GTK with the problems. When I rename the file to a new
> directory with this
Scratch my last. It is GTK with the problems. When I rename the file to a
new directory with this patch, the tree never seems to update. I have to
manually refresh it in order for the file to appear in the correct place.
-Ian
On Fri, Nov 15, 2019 at 10:21 PM Mikołaj Wielgus
wrote:
> Yes, I'm
Yes, I'm on Windows (the details are in the linked related bug report).
Sorry for the return value problem -- I failed to notice the warnings in
console.
Best regards,
Mikołaj Wielgus
On Fri, Nov 15, 2019 at 11:07 PM Ian McInerney
wrote:
> I'll give it a test on GTK once my build here
I'll give it a test on GTK once my build here finishes, but I don't think I
have seen any issues with file watcher on GTK in the past.
-Ian
On Fri, Nov 15, 2019 at 10:03 PM Jeff Young wrote:
> Hi Mikolaj,
>
> The Mac compiler doesn’t like Rename() returning values when the return
> type is
Hi,
Renaming file to a different directory causes the entire project tree to be
recreated, which causes all subdirectories to collapse, unexpectedly to the
user.
This patch solves the problem by deleting the original node after moving
the file. Then the file watcher raises an event whose handler
12 matches
Mail list logo