[Eric] a few eric4 usability issues

[Hans-Peter Jansen]

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.

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?

> > 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?

> > 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 ;)

Pete