[Eric] a few eric4 usability issues

[Detlev Offenbach]

On Donnerstag, 27. Januar 2011, Hans-Peter Jansen wrote:
> On Thursday 27 January 2011, 19:20:17 Detlev Offenbach wrote:
> > On Mittwoch, 26. Januar 2011, Hans-Peter Jansen wrote:
> > > Hi Detlev,
> > > 
> > > I would like to discuss some usability aspects of eric4:
> > > 
> > > Autocompletion: I would like to have autocompletion working for
> > > translated ui files,
> > 
> > I gues you mean "compiled" ui files, i.e. Ui_*.py files.
> 
> Yup.
> 
> > > but it seems, that no combination of settings
> > > 
> > > allows me to do so:
> > >  * Autocompletion is enabled, case sensitive, replacing words with
> > >  
> > >    threshold 2
> > >  
> > >  * Eric AC is enabled from API files, document, and project
> > >  
> > >    (but doesn't seem to work)
> > 
> > Is it enabled?
> 
> Yes.
> 
> > >  * QScintilla AC is enabled bot showing singles, not using fillup
> > > 
> > > chars with document and API files sources
> > > 
> > > The latter seems to work fine, but isn't able to use any project
> > > members apart from the current document.
> > 
> > QScintilla doesn't support dynamic scanning of project files. That's
> > why I implemented the "Eric Assistant" plug-in, which does exactly
> > this. It scans a project file upon saving it. If this plugin doesn't
> > work, please check the directory .eric4project in your project. Maybe
> > there is a lock file for the API database.
> 
> Ahh, I see, it scans for changes on project save only.

It scans whenever a source file belonging to the project is changed.

> 
> Okay, but no, it doesn't work, although there's no stray lockfile
> in .eric4project/, just the project-apis.db and 3 .e4* files.
> 
> Might it be related to me operating on a Qt3 project? The ui files are
> just local source files, they aren't members of the svn project, btw.
> Is there any sqlite dumping tool to check its contents?

eric includes a little tool to inspect databases (eric4-sqlbrowser). It can be 
started from within the IDE as well (tools toolbar).

> 
> > > I've disabled Rope AC, since it operates in a too intrusive way.
> > > 
> > > Do I really need to manually create api files on any UI change and
> > > add an API file for every project?
> > 
> > No, if you use the plug-in.
> > 
> > > Other files handling: usually, one selects some changed files in
> > > the project viewer in order to check them in. Loading the
> > > associated app isn't the best thing to do, when selecting them,
> > > especially, if you click on them with some accelerator key pressed
> > > (to select many or regions of files). It's simply not funny, that
> > > eric triggers a dozen oowriter instances in that case. Better
> > > provide that as a context menu item. Same goes for UI files.
> > 
> > Did you select several files and opened them via the context menu? I
> > don't quite understand the sequence of actions.
> 
> Add a few odt or ods files to your project. Now try to select them in
> the project view in order to add them for example to a vcs repo. One
> would do that by pressing Ctrl and clicking left on each file item.
> Close all instances of OOo, when they appear. Everytime you add another
> file to your selection, you execute OOo for all files.
> 
> Executing the default (left click) action for all file items in a
> selection during the course of selecting multiple files every time you
> add another file is, hmm, strange, isn't it?

Is your desktop set to open files upon double- or single-click? The later has 
caused me trouble as well. Unfortunately I haven't found a way to resolve the 
single-click issue (except by switching the desktop to double-click open).

> 
> > > Check in: I tend to prefer checking in larger changes on the
> > > command line (to svn), since that gives me the hint, what files are
> > > checked in beforehand. Ideally, I would want to check the diff of
> > > some files' changes before proceeding. I'm dreaming of a check in
> > > facility, that offers an interface similar to "svn ci" in the
> > > shell, but with the possibility to check the diffs of certain
> > > files, or a full diff. You offer all of these functions within the
> > > version control context menu, but the workflow is pretty
> > > uncomfortable.
> > 
> > That would be a dialog like kdesvn commit dialog, right?
> 
> Yes, something similar, although that dialog suffers from its attempt to
> manage new files by default..
> 
> > > It's a real pity, that you dropped Qt3 support a long time ago.
> > > Since I still have a host of such projects running, I feel
> > > discriminated compared to, say, wxpython users (which I classify
> > > much more legacy then Qt3..).
> > 
> > Can't you use the last eric3 anymore? ;)
> 
> Oh well, not lately. Should I ;)

Not really. You better port your Qt3 stuff to Qt4 and ideally to Python3 (all 
that using eric5).

Detlev
-- 
Detlev Offenbach
detlev at die-offenbachs.de