Ozgur Ugras BARAN wrote: > Maybe.. but, you know, in some day users will complain as, where is my > twentieth index etc. The problem here is to keep track of number of > writes, some of which are not index related files, not to exceed > number 16. My programming habits tell me I should control it for the > sake of consistency. But, I am too lazy/ have too little time to > implement it. This is why my first choice is splitidx.
Then we are in complete agreement. > I have already sent the inetcommandparams changes. There is no change > for insetcommand from me.. Georg will improve it a little and submit > to svn, i guess.. This is necessary also for my nomencl > implementation.. OK, what I meant is: if there will be more changes, it might be tricky for you to maintain your tree (because there might be conflicting changes). > we are thinking in parallel then.. My only concern is for index.sty > there are four obligatory and one optional parameter. it will be hell > of a crowded dialog.. This number reduces to two for spliidx.sty. I think the user should only see the and enter the "Index Name" parameter (which should then be visible in the index dialog dropbox). All other parameters are interal shortcuts, which are of no concern for the LyX users (because they use the combo box and they do not have to run makeindex/xindy manually). So those should be created automatically. BTW I forgot one element: The \printindex inset will also need a dialog, where the user can chose which index it represents (similar to the bibtex inset) > > > - I have limited time. I mean in two months, I will probably disappear > > > for six months. therefore I need somebody to maintain the code when I > > > am away. I am sure that I will finish a working and clean version > > > before I leave, but I cannot guarantee things will work in every > > > frontend. > > > > I'll try to, but I cannot guarantee anything, since my time is limited as > > well. But I'm interested in helping to polish it. > > that is what I am asking. And (if I don't have time) qt3 and gtk ports.. The least I can do is the port to qt3 (and testing). Jürgen > > Jürgen
