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 [email protected] _______________________________________________ Eric mailing list [email protected] http://www.riverbankcomputing.com/mailman/listinfo/eric
