[bt-devel] General development questions re installmgr

[Tim Brodie]

> Hi Tim!
> make -f Makefile.cvs is required if a new subdirectory with a Makefile.am
> inside of it is added in CVS. ./configure have to be run after make -f
> Makefile.am to create the new Makefiles.
>
> Updating with "cvs -z5 up -Pd" should create new subdirectories, so you
> should at least get the new directories froom CVS.
>
> >     After letting everything recompile, BT showed the splash and
SIGSEGV.
> >     So now I must download the 1.0 release tarball, and have to
> >     recompile the world again to try to find the problem.
>
> This is a bad way. Do not try to fix the bug if you have not introduced
it.
> Other developers who comitted the new code are knowing better where the
bug
> may be. If you get a crash write to this mailing list and you'll get
> (probably) soon some help with the bug. Don't forget to include some
> backtraces and infos shown by Dr. Kongy.
> Sometimes the local directoy gets mixed up and causes a SIGSEV. make
> distclean and a new compile session after this should solve this.

I wasn't trying to fix the problem, just determining where it is (that
is, is it my problem or someone else's).  After recompiling the 1.0
release I still had the same problem.  So finally, it turned out to be
a problem with my sword build... somehow it got corrupted.  Anyway,
I'm back on track now.

Terribly frustrating, though.  I had 6 hours to work yesterday, and
it took 4 hours to get to be 'functional' again.  I've set some of the
cvs options in my $HOME/.cvsrc file (that Martin gives in a later
email), but not all.  I will change to use all the suggested options
and hopefully keep this problem from re-occuring.

> Do you want to add the installmgr to the optionsdialog?
> Please don't forget, that the interface of the installmgr may get bigger
so
> it's hard to integrate it into the optionsdialog. And it should be
possible
> to open the installmgr using a command line option.
> If you have questions about this please ask me.
>
> This is my opinion and it's probably not the best. I'm open for discussion
> about this point.

Sure, would be glad to discuss it.  I was thinking about adding an icon
to the optionsdialog list that would bring up a page to display a list
of currently installed modules.  Also on this page would be a button
"Configure Modules..." that would open the installmgr dialog.  This
dialog would designed to be reusable (when used by an external
stand-alone program as well).  This would be a modal dialog on top
of a modal dialog... lots of other examples of this in KDE, but does
this fit our look and feel?

I'm thinking that the installmgr dialog should enable the user to select
the module source from either a local directory (default /mnt/cdrom)
and/or an ftp site (default ftp.crosswire.org).  We could use ssh ftp
(if /usr/bin/sftp is installed), or a regular ftp client (such as ncftpget).

[Q: I have heard that some common TCP/IP socket support is built into
QT/KDE.  Should I be using library calls for ftp access, or external
utilities?]

I was also thinking that if a module is selected for install that requires
a special font, that I should install it?  We should have at least two
font types available for each module: TT and Type1 (as a backup if TT
support is not installed)?  For these modules, I should set the initial
font to the TT font, say at 12 point?

[Q: Does a font installation need to be installed globally for X to be
able to use it, or can a user install their own fonts in their $HOME?]

I like the idea of determining if installmgr has root or not, and asks
for either root passwd or use $HOME for install.  The only problem I can
see with this is that some Unices have the /home partition set noexec
(for security reasons), and we will not be able to run BT there.  (We
could run a test program from $HOME and let the user know that the
install there would be a waste of time?)

[Q: Or were you all thinking that just the modules would be installed
in $HOME?]

> IMHO the solution would be to add a new menu item and to create an own
dialog
> for the installmgr.

I certainly can do this as well, if this better fits the look and feel
of the product.  I was thinking more of providing just a module list
report under the options dialog with the real install/config work in
another dialog. What do others think?

BTW, my suggested code did work as advertised :-)... hopefully things
will become easier with time (instead of rebuilding my development
environment).

[Q: What is the best situation to use signal/slot pairs, as opposed
to modal fields (such as used by the general options page)?]

Thanks again for your help.

--
Tim Brodie/ CTO
Display Works Inc.
90 Milvan Drive, Toronto, Ontario, CANADA M9L 1Z6
Voice: 416-740-9677 x29   Fax: 416-740-9971