head	1.6;
access;
symbols
	V0-3-1:1.5;
locks; strict;
comment	@# @;


1.6
date	2000.07.25.11.25.27;	author wkoch;	state Exp;
branches;
next	1.5;

1.5
date	2000.05.25.14.37.36;	author wkoch;	state Exp;
branches;
next	1.4;

1.4
date	2000.05.21.18.46.16;	author wkoch;	state Exp;
branches;
next	1.3;

1.3
date	2000.05.16.17.35.11;	author wkoch;	state Exp;
branches;
next	1.2;

1.2
date	2000.05.10.15.52.16;	author wkoch;	state Exp;
branches;
next	1.1;

1.1
date	2000.02.08.08.54.49;	author wkoch;	state Exp;
branches;
next	;


desc
@@


1.6
log
@Changed copyright notice.  Except for GPAPA legal papers are not anymore
required.
@
text
@
 - All dummy functions are marked by a comment containing !!!.

 - Not yet done: Check for memory leaks.

 - Dialogs: Set them up to find their size and position independently of the
   window manager!
     wk: Why?

 - File dialogs: Let them _not_ be placed via mouse! Let them get to their
   standard position as every dialog else.
     wk: Why?

 - File dialogs: Initialization!

 - File dialogs: Check selected file for validity -- e.g. in the homedir
   dialog, if the selected path really is a directory.

 - Sign dialogs: There's one file_sign_dialog now for the file_sign,
   file_encrypt and key_openPublic_sign processes; in every case, it carries
   a lot of information that's not needed. It should be replaced by three
   independent dialogs, every one specialized for its own purpose. (Hell,
   GPA should be written in a _really_ object-oriented language...!)
     wk GTK+ is implements an complete messaging and inheritance system;
	aka OO.

 ? File clist: The file status isn't correctly recognized. Why?

 - Implement some widget with a progress bar -- signing and encrypting lasts
   quite long.

 - Up to now, all of the dialogs work on the list of currently selected
   files. They should better work on a copy of this list, made at the moment
   where the dialogs are created. Same thing with dialogs that work on a key
   list.

 - Implement the feature of differentiating between name and identifier of a
   file. (For "normal" files: name = identifier without pathnames; for
   mails: name = "Mail from/to ... [Date]")
   => In the file/show Detail dialog: Additional read-only entry with the
      complete file identifier! In the main file clist: tooltips with the
      complete file identifier(?).

 - Implement command line parameters to start GPA with
   - a given file or file list (thus enabling "Wind$$s Double-Clicking")
     (use function file_add from module filemenu.h of GPA)
   - a given key (import them at once and open key ring editor(?))

 - Insert new menu item: "Sign and save as"? Or remove all the "save as"
   menu items for other processes? (Symmetry!)

 - Public key ring editor:
   ? "Delete keys" still yields a segfault...

 - frameExpire: fill entryAfter and comboAfter with reasonable values,
   calculated from the key's expiry date.

 ? gpapa_import_ownertrust doesn't yield an error message when the file to
   import from doesn't exist.

 - In all "Sign as" dialogs: In the resp. clists, initialize the scrollbars
   as to present the selected row (AKA the default key).

 ? Set/get the list of default recipients.

 ? Set/get the home directory.

 ? Load/save options file.

 ? Show warranty information.

 ? Help texts.


FOR VERSION 2.x:

 - Implement a unified way of keeping clist selections in memory. Currently,
   it's a chaos...

 - Include import functions into key editors? (Hmm, better wait for feedback
   by users before starting this...)

 - Implement some command pattern or similar stuff to enable undo
   operations?
@


1.5
log
@A few changes done at Utrecht and elsewhere
@
text
@a69 3
 - Tips dialog and license dialog: Instead of texts shown now, insert file
   contents.

@


1.4
log
@Added missing files in jnlib
@
text
@d1 87
a87 85

 - All dummy functions are marked by a comment containing !!!.

 - Not yet done: Check for memory leaks.

 - Dialogs: Set them up to find their size and position independently of the
   window manager!

 - File dialogs: Let them _not_ be placed via mouse! Let them get to their
   standard position as every dialog else.

 - File dialogs: Initialization!

 - File dialogs: Check selected file for validity -- e.g. in the homedir
   dialog, if the selected path really is a directory.

 - Sign dialogs: There's one file_sign_dialog now for the file_sign,
   file_encrypt and key_openPublic_sign processes; in every case, it carries
   a lot of information that's not needed. It should be replaced by three
   independent dialogs, every one specialized for its own purpose. (Hell,
   GPA should be written in a _really_ object-oriented language...!)

 ? File clist: The file status isn't correctly recognized. Why?

 - Implement some widget with a progress bar -- signing and encrypting lasts
   quite long.

 - Up to now, all of the dialogs work on the list of currently selected
   files. They should better work on a copy of this list, made at the moment
   where the dialogs are created. Same thing with dialogs that work on a key
   list.

 - Implement the feature of differentiating between name and identifier of a
   file. (For "normal" files: name = identifier without pathnames; for
   mails: name = "Mail from/to ... [Date]")
   => In the file/show Detail dialog: Additional read-only entry with the
      complete file identifier! In the main file clist: tooltips with the
      complete file identifier(?).

 - Implement command line parameters to start GPA with
   - a given file or file list (thus enabling "Wind$$s Double-Clicking")
     (use function file_add from module filemenu.h of GPA)
   - a given key (import them at once and open key ring editor(?))

 - Insert new menu item: "Sign and save as"? Or remove all the "save as"
   menu items for other processes? (Symmetry!)

 - Public key ring editor:
   ? "Delete keys" still yields a segfault...

 - frameExpire: fill entryAfter and comboAfter with reasonable values,
   calculated from the key's expiry date.

 ? gpapa_import_ownertrust doesn't yield an error message when the file to
   import from doesn't exist.

 - In all "Sign as" dialogs: In the resp. clists, initialize the scrollbars
   as to present the selected row (AKA the default key).

 ? Set/get the list of default recipients.

 ? Set/get the home directory.

 ? Load/save options file.

 - Tips dialog and license dialog: Instead of texts shown now, insert file
   contents.

 ? Show version information.

 ? Show warranty information.

 ? Help texts.


FOR VERSION 2.x:

 - Implement a unified way of keeping clist selections in memory. Currently,
   it's a chaos...

 - Include import functions into key editors? (Hmm, better wait for feedback
   by users before starting this...)

 - Implement some command pattern or similar stuff to enable undo
   operations?
@


1.3
log
@Markus's last chunk of code changes.
He did quite a professional job to design and code the base of GPA.
Kudos to him and thanks to the BMWi for funding this development.
@
text
@d1 85
a85 77

 - All dummy functions are marked by a comment containing !!!.

 - Not yet done: Check for memory leaks.

 - Dialogs: Set them up to find their size and position independently of the
   window manager!

 - File dialogs: Let them _not_ be placed via mouse! Let them get to their
   standard position as every dialog else.

 - Sign dialogs: There's one file_sign_dialog now for the file_sign,
   file_encrypt and key_openPublic_sign processes; in every case, it carries
   a lot of information that's not needed. It should be replaced by three
   independent dialogs, every one specialized for its own purpose. (Hell,
   GPA should be written in a _really_ object-oriented language...!)

 ? File clist: The file status isn't correctly recognized. Why?

 - Implement some widget with a progress bar -- signing and encrypting lasts
   quite long.

 - Up to now, all of the dialogs work on the list of currently selected
   files. They should better work on a copy of this list, made at the moment
   where the dialogs are created. Same thing with dialogs that work on a key
   list.

 - Implement the feature of differentiating between name and identifier of a
   file. (For "normal" files: name = identifier without pathnames; for
   mails: name = "Mail from/to ... [Date]

 - Implement command line parameters to start GPA with
   - a given file or file list ("Wind$$s Double-Clicking")
     (use function file_add from module filemenu.h of GPA)
   - a given key (import them at once and open key ring editor(?))

 - Insert new menu item: "Sign and save as"? Or remove all the "save as"
   menu items for other processes?

 - Public key ring editor:
   ? "Delete keys" still yields a segfault...

 - frameExpire: fill entryAfter and comboAfter with reasonable values,
   calculated from the key's expiry date.

 ? gpapa_import_ownertrust doesn't yield an error message when the file to
   import from doesn't exist.

 - In all "Sign as" dialogs: In the resp. clists, initialize the scrollbars
   as to present the selected row AKA the default key.

 ? Set/get the list of default recipients.

 ? Set/get the home directory.

 ? Load/save options file.

 - Tips dialog and license dialog: Instead of texts shown now, insert file
   contents.

 ? Show version information.

 ? Show warranty information.

 ? Help texts.


FOR VERSION 2.x:

 - Implement a unified way of keeping clist selections in memory. Currently,
   it's a chaos...

 - Include import functions into key editors? (Hmm, better wait for feedback
   by users before starting this...)

 - Implement some command pattern or similar stuff to enable undo
   operations?
@


1.2
log
@As usual - however, this time it doesn't build
@
text
@d2 26
d32 14
d49 11
d61 1
a61 1
FOR VERSION 1.x:
d63 6
a68 9
 - Two possible ways of avoiding "modal" problems:
   1. All of the windows do exist all time; they're never destroyed, just
      hidden.
   2. Every window _really_ is an object (i.e. a struct in this case). The
      parameter pointers to pass to signal functions are not static, but
      fields of these structs. Every window gets a constructor (they're
      what is already existing in GPA 0.x) and a destructor, taking care of
      the parameter pointers.
   (Hell, what we need is a _really_ object oriented GUI lib!)
d72 6
@


1.1
log
@initial checkin
@
text
@d1 23
@

