Re: Pre-release for testing - UPDATE
- From: <tpgww@xxxxxxxxxxx>
- To: emelfm2@xxxxxxxxxxxxx
- Date: Sun, 15 Jul 2007 16:03:13 +1000
On Sat, 14 Jul 2007 16:21:11 +0400
Alexander Orlov <alxorlov@xxxxxxxxx> wrote:
> On Sat, 14 Jul 2007 11:09:16 +1000
> <tpgww@xxxxxxxxxxx> wrote:
> > > > > 4) Tree view has many bugs.
> > And now I see them:
> > - if you don't have permission to read a directory, it should show without
> > any descendants, instead of being omitted altogether (now fixed)
> > - bad additions to the treeview widget, when scanning down a level (now
> > fixed, I think)
> > - some small bads in the text messages printed when a directory can't be
> > opened (now fixed, but also, see below about warnings)
> Yes, now that problems are solved.
> But one still exists: Hidden dirs are not shown. I go into some dir, that
> contains hidden dirs. Emelfm2 puts all hidden dirs in the first non-hidden
> dir in current subtree. http://alxorlov.pochta.ru/emelfm2/screen6.png
> illustrates this. In addition emel multiplyes that hidden directories. In the
> screenshot: .cache have 4 subdirs, so there is 4 clones of .cache; .config
> has 7 subdirs; .dbus has 1 subdir, and so on.
> When hidden directories are toggled to be shown, everytnig is all right.
Fixed now.
> > As to the error-beeps, I think that in these "tree" views, there does not
> > need to be a warning message about dirs not opened, because "problem" dirs
> > show in red text (or whatever color is set is for error messages). I've
> > removed the warnings.
> Yeah, this is what I was talking about. Thank you.
>
> Now I have found another couple of bugs.
> plugin:unpack action is not working now.
> When I try to unpack package with it, emel2 takes me into
> /tmp/1000-emelfm2-unpack.tmp dir, but the dir remains empty. No error or
> warning messages are printed. Just nothing happens.
Fixed now. Also, cleans up if the unpack command fails.
> Trying to print file hangs emel2.
> I have no printers. CUPS server is installed, but not running now.
> So, when I view file, and try to print it, view-dialog just turns blank, and
> hangs forever.
> When I start CUPS server then printing goes OK.
> Another one problem. I am using evince for view pdf's, but it has no
> --preview option. So when I try to preview document it just print error
> message and shows nothing.
In concept, gtk printing works quite simply. The print dialog (with its preview
button) and previewing and actual printing are all pretty-much done outside of
the application. The application just passes the text to print to gtk.
Essentially a single function-call. Printing works asynchronously, so should
not freeze anything unless the function never returns.
So all that e2 could do is to pre-check for absence of "real" print
functionality and/or preview capability, and if test(s) not satisfied, don't
add the print item to the context menu.
So, anyone got any ideas on how to universally detect in advance whether
printing works?
I can find what evince version is needed to allow previewing, and check for
that. BTW, evince has lots of dependencies outside of gtk, many of them
gnome-specific, its usage in a gtk-context is therefore bad, IMHO. Does anyone
know whether evince is the only app for print previewing ?
(BTW, I can't test printing, my printing is defunct since a MOBO upgrade.)
On an older matter, management of multi-action plugins in config dialogs is now
reasonably robust.
> Many thanks for fast responses. I hope, I don't bother you with my requests.
> :)
Not at all, we're here to fix problems.
Regards
Tom
--
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:
