Re: new pre-release available
- From: Grégory SCHMITT <gy.schmitt@xxxxxxxxx>
- To: emelfm2@xxxxxxxxxxxxx
- Date: Sat, 26 Sep 2009 11:49:34 -0400
Le Sat, 26 Sep 2009 09:31:14 +1000,
<tpgww@xxxxxxxxxxx> a écrit :
> On Fri, 25 Sep 2009 19:10:58 -0400
> Grégory SCHMITT <gy.schmitt@xxxxxxxxx> wrote:
>
> > Le Fri, 25 Sep 2009 17:12:04 -0400,
> > Grégory SCHMITT <gy.schmitt@xxxxxxxxx> a écrit :
> >
> > > Le Sat, 26 Sep 2009 06:41:35 +1000,
> > > <tpgww@xxxxxxxxxxx> a écrit :
> > >
> > > > On Fri, 25 Sep 2009 12:34:47 -0400
> > > > Grégory SCHMITT <gy.schmitt@xxxxxxxxx> wrote:
> > > >
> > > > > Le Fri, 25 Sep 2009 19:23:19 +1000,
> > > > > <tpgww@xxxxxxxxxxx> a écrit :
> > > > >
> > > > > > On Fri, 25 Sep 2009 15:39:40 +1000
> > > > > > <tpgww@xxxxxxxxxxx> wrote:
> > > > > >
> > > > > > > On Thu, 24 Sep 2009 15:34:36 -0400
> > > > > > > Grégory SCHMITT <gy.schmitt@xxxxxxxxx> wrote:
> > > > > > >
> > > > > > > > Le Thu, 24 Sep 2009 20:24:28 +1000,
> > > > > > > > <tpgww@xxxxxxxxxxx> a écrit :
> > > > > > > >
> > > >
> > > > > I downloaded revision 1911, and here are my results so far:
> > > > > - Control-W binding: fixed, works, no warning.
> > > > > - Segfaults: mostly gone. I didn't run an in-depth test
> > > > > session, but I haven't suffered a crash at the moment.
> > > > > - GTK widget size: when I click on the magnifying glass to
> > > > > toggle the output pane with a height of 100%, this is what I
> > > > > get:
> > > > >
> > > > > Gtk-WARNING **: gtk_widget_size_allocate(): attempt to
> > > > > allocate widget with width 40 and height -9
> > > >
> > > > This has always happened. Similarly when pane 1 or pane 2 is
> > > > maximised. It seems that gtk's GtkPaned widget (the movable
> > > > divider thingie) is not smart enough to handle the case where
> > > > the divider is near or at an extreme position. It's complicated
> > > > to figure out when to [un]hide specific widget(s), and the
> > > > application may not want that anyway. There's no evident
> > > > consequence from such allocation attempts, IMHO gtk should not
> > > > issue the warnings. So I ignored them.
> > > >
> > > > >
> > > > > Otherwise, the behaviour is absolutely fine and exactly as
> > > > > expected; I haven't encountered any issues with it.
> > > > >
> > > > > - Configuration reloaded on change: unreliable. emelFM2 will
> > > > > occasionally catch the change and reload itself; sometimes, it
> > > > > won't detect anything, and in some cases, emelFM2 will freeze
> > > > > completely (no segfault though, Control-C will close it).
> > > > > Although I did not find a way to guarantee exact reproduction,
> > > > > the bug seems to happen frequently enough and may be repoduced
> > > > > fairly easily.
> > > >
> > > > What sort of change-monitoring are you using i.e. inotify etc or
> > > > just the default (polling for mtime change) ?
> > >
> > > inotify. I'll try an other change-monitoring system (most likely
> > > emelFM2's built-in polling system, since I don't run dnotify or
> > > any userland polling system).
> >
> > Just tried emelFM2 built-in polling system, identical behaviour.
> >
> > Changes brought to emelFM2 configuration file will make emelFM2
> > reload it, take changes in account, but emelFM2 subsequently stops
> > behaving properly (i.e is unusable, won't browse folders, etc.) and
> > will quickly freeze.
>
> I just reinstated into the re-creation process a thread-lock that was
> removed as it seemed irrelevant. That may help.
Just tried revision 1914.
First of all, do we agree if I say that emelFM2 is only polling for
mtime change, not atime ? I have my /home filesystem set with "noatime,
relatime" options in fstab, and I wondered if they could cause any
trouble.
I have experienced different behaviour using different text editors,
and here's what I have found so far when modifying a file:
- mcedit will update ctime & utime, but not atime
- emacs will update a/m/ctime
Using mcedit to change the config file will affect emelFM2 as the
configuration is reloaded. However, using emacs, emelFM2 doesn't catch
anything. Furthermore, using mcedit AFTER emacs won't do anything.
I might be wrong, but it seems that emelFM2 polls for any modification
by calculating the difference between atime and mtime; if positive,
configuration is reloaded, if not do nothing.
--
Grégory SCHMITT <mailto:gy.schmitt@xxxxxxxxx>
--
Users can unsubscribe from the list by sending email to
emelfm2-request@xxxxxxxxxxxxx with 'unsubscribe' in the subject field or by
logging into the web interface.
Other related posts:
