
* check tracksize for 192kbit MP3 files

* automatic updates on both dirtree and filelist with keeping selections

* display a progress box when copying files and
  removing files
  
* make record.c immune for stderr buffer overflows while reading
  data from trackpipe (set O_NONBLOCK: -1 no data avail,0 end of file)
  
* investigate into that oddball "bug" of GtkTree,see Changelog

* implement stream copy in fileman.c

* maybe give back error string if track is not available,adapt record.c
  to give the user a chance to react on the error by for example inserting
  the right cdrom.

* implement cdrom drive autodetect

* (introduce check if recording on exit),obsolete as user shouldnt be able
  to normally exit if recording process is running any more

* implement check functions wether the right cdrom is inserted

* write import and export functions for trackedit - (those would have
  to be managed partly by the tracktype handlers themselves,requiring
  another callback,also some register database would have to be created,
  where every tracktype would have to install itself using a unique 
  identifier,so that the import loader could recognize the tracktype
  and reinitialize the trackstruct accordingly.)
  Why so much work ? There seems to be some demand for projects
  (files that store informations about a cdrom created with GnomeToaster,
  sos for example an audio cd can be remastered by simply selecting the
  related project file and clicking record)

* (make the progress box update when reading "fast" data streams.
  Chris mentioned we could force the screen updates there calling some
  specific gtk functions.) did anyone watch this behavior recently ?

* maybe create a fileselect dialog instead of letting the user enter the
  whole path into a text box in preferences
  
* refer to cds using the cddb code as obtained from cdromlow_cddbnumber in 
  audiotrack.c and datatrack.c and create lookup table to determine in which 
  drive the corresponding cd currently resides

* combine the various vartabs (dynamics,statics) by linking them together

* add support for reading multisession cds

* solve the cd change update enable/disable rom-wise within the main structure
  (maybe this is not as good an idea for ide systems where an error on one
  drive can cause all the others to hang)

* introduce multi-recorder support someday.This should be included in the
  new drive setup mentioned below.

* replace cdrecord call for eject by a ioctl() doing the same job (we had this
  with tracksize detection already ;-)) 

* have some thoughts on a configuration wizard as configuring Gnometoaster is
  still hell for an absolute beginner.
  
* design a network protocol for crossusing streams throughout several
  instances of Gnometoaster running on the same computer.

* take a look at the GVoice package and determine how difficult/easy it would
  be to add voice control support to Gnometoaster using IBMs ViaVoice
  Package. This *does* have time,though.It was just an idea  ;-)
  
* take care about quotation marks in filenames. They have to get converted
  to \" when used in a piping call. Write a convenience function for that.

* let the user edit a specific tracks precaching flag.

* why does Gnome Toaster crash when the user stops precaching with recent
  versions of cdda2wav ? (shouldn't be an issue any more)

* apparently Gnometoaster sometimes crashes if cdrecord is not available.
  it should just give an error message and behave nicely in that situation.
  (see above)

* create an extensive drive setup within preferences,combining cd recorder
  setup,drive setup and specific drive settings within one list.
  Every cd recorder should get its own cdda2wav and cdrecord call line,
  but let the user decide on wether he wants different settings for each drive
  or if he just wants to use a default setting he can enter for all drives
  together. This will be rather complex,but the current system is pure shit.
  My cd recorder is ide-mmc3 compliant and works with cdda2wav and /dev/sg,
  while my cdrom is not ide-mmc3 compl. and thus has to be accessed with 
  /dev/scd1 by cdda2wav

* (update Documentation (esp. add a section about the new filetype registry).)

* apparently we do have a problem with stack management: as chris discovered
  shortly,sometimes errpp and outpp in piping_create_getoutput() get
  overwritten during the piping_create() call. This is very very odd and
  i was unable to reproduce the problem on my system until now.
  At Chris computer we did however manage to crash Gnometoaster with
  a segfault once. This stays to be investigated...
  (hasn't happened for quite a while now)
  
* some thoughts on what should happen if a user drags a stream to the
  filesystem editor:
  There should be a database pretty much the same as it would be the other
  way round,only that a certain filetype is now connected to
  and identified by a track type.If more than one filetype is 
  associated to a track type the user should be asked which one to use...
  This should enable reading out audiotracks and converting them to mp3
  almost without delay (if youre using a fast encoder,say xings or
  something).
  
* scan source for possible buffer overflows.Theres quite a lot of them,
  especially within stringhandling functions.
  
* migrate dircache to GList structures. This has the
  advantage of a virtually unlimited number of entries.
  
* dircache does have a bug: stale symlinks will stay stale even if the
  directories they refer to become available again.
  I dont know how important this is. However,the only way to fix this
  problem would be to completely remove the dircache function from
  Gnometoaster as wed have to read the inode anyway,then.
  Actually,one functionality of the Dircache would remain: the question,
  if there are any subdirectories within a directory could be answered
  by checking the timestamp without having to actually read the directory
  structure. Maybe that would already be strong enough a reason to keep
  the cache,as checking for subdirectories requires another inode read
  for each file found within the dir.
  
* catch hard directory links and avoid recursive loops if they occur.

* make all stream copy functions O_NONBLOCK and create a highly responsive
  user query system to be used when reading errors occur. Using this system,
  Client programs should be able to do user queries by writing special
  command sequences into a shared memory segment and/or  maybe sending a user-
  defined signal to the main process. All communications with the user
  should then be done by the main process to avoid X protocol complications.
  This might finally be the way to implement a user error handling protocol
  into gnometoasters trackstream concept.
  This does,of course,require the client to know about that means of communi-
  cation,so that I plan to use this for streams with direct file access only
  (eg. datatrack readers)
  
* integrate "read essential data only" into Gnometoaster,together with an
  error-tolerant mode,to bring some basic copyprotection removal capabilities
  into Gnometoaster
  
* detect cd-type inserted into a cdrom and maybe make an option to
  automatically precache data *read* from a cdr. (dont know how many cdrom
  drives can detect the cd type though,its probably just the recorders
  being capable of doing so :-/ )
  
* make Gnometoaster work on 64 bit and big endian systems (this may require
  some extensive use of compiler directives)

* when default filetype handler is added,not only prepend it to the list
  but also display it on top. To solve that problem,I would have to know how
  I could insert a widget on top of a gtk_vbox.

* introduce optional hiding of "." files

* investigate in wether to use OrBIT to export tracks. This could be an
  elegant way to let various instances of Gnometoaster share track streams.

* support KDE drag and drop (this will hopefully no longer be an issue
  with Kde 2.0)

* (apparently there are still problems running gtoaster with FreeBSD.)
  [there is now an official FreeBSD port. It's still got some problems,though]

* implement the possibility to specify the tracksize to cdrecord on the
  command line. Well probably have to calculate the tracksize more
  accurately for that purpose.
  Some cd recorders must know the tracksize prior to writing them.
  Apart from that accuracy issue,patching gnometoaster for that purpose
  should be rather easy.
  
* implement a filetype handler for midi (timidity) and mod (mikmod or
  something like that)
  
* if dropped into the middle of the tracklist,multiple tracks get added
  in the wrong order
  
* highlight drop position in tracklist

* rearranging doesnt work for the last track in the list

* make gnometoaster work with big endian sound boards (are there any ?)

* implement configure screens for the different audio drivers

* think of a "bridge" implementation for the preview player in the tracks
  definition. With that,we could use external devices for playing certain
  track types (like using a cdroms built-in audio player functionality
  instead of piping the data through the soundcard digitally. Could also
  be used for a stdfiletrack type .mid to play them through a wavetable 
  board. As this functionality strictly has to be configurable (and this means
  that we do at least have to let the user decide on a per-drive basis wether
  he wants to take the direct way or not),well have to do a lot of work
  to gnometoasters configuration menus first.
  
* [why does mpg123 get a thrill out of malfunctioning during preview play
  if gtoaster gets run from gnome mini-commander ? 
  (a rather complicated one,ey ? I suspect that it is not gnometoasters
  fault. thats what I think could be the problem:
   if you run gnometoaster from a terminal,stdin gets connected to the xterm
   if you run gnometoaster from the gnome menu,stdin gets connected to
   /dev/zero,which is ok. But if you run gnometoaster from the minicommander,
   stdin points to a pipe,which is probably opened later and not handed down
   to gnometoaster as its stdin. So I expect minicommander just messes 
   stdin,leaving it the first fildescriptor available for open calls
   -> when gnometoaster forks,it closes stdin for the child process and
   connects the file stream there instead- who the hell knows what happens
   if you disconnect an essential pipe to x or something like that ?
  Of course this is only a rough guess. Let me know if you can provoke the
  situation of gnometoaster hanging for several seconds when you stop a mp3
  file with the stop button of the preview player by other means than running
  gtoaster from minicommander. I couldnt,so I couldnt go into detail about
  what might cause that problem yet.

  update on the above issue: in my current configuration (since I updated
  to kernel 2.2.13 I think),I got the same problem regardless of where
  I run Gnometoaster from.]
  
  currently,this issue es solved by generally sending a sigterm 
  signal to mpg123. This seems ok so far but is it really necessary ?  
  

* segfault when second mp3 file is dropped ?!? (I could not reproduce 
  that one)
    
* make Gnometoaster compile/work on freeBSD
  (there are people working on that one)

* ALSA Support

* think about an audio editor (win progs swear on that stuff,I'd personally
  prefer a good external one,but well...)
  It should be available for precache tracktypes only (we're gonna
  introduce an "already_precached" flag anyway)

* adapt clist column sizes in a more sane way when window is resized

* read out cd-text (will need a cd-text capable drive for that someday)

* mark source and destination section

* create drives overview displayed when the user clicks on cdrom drives.
  this overview should show informations about the cds and the drives them-
  selves
  
* make "drives" draggable from both this list and the main source tree
  to the track editor and maybe the dao writer in later versions...
  drag data should get a drive:/dev/scd0 or something identifier
  
* let user select *way* of precaching for file->track conversion instead of
  precaching it ATADD
  
* change the way the popup menus of the gtk version behave

* implement some warning dialog with reaction in dialog.c

* how could we enable scrolling of the client output window while at the 
  same time keeping the progress dialog modal ?

* Gnometoaster's Cover editor will be Gnome only - If you don't like it,
  say so until it's too late ! 
  Background: I think the Gnome Printing system is worth using - but this
  makes sense if you don't recode it work the gtk version only of course.

* get cd size and informations from cdrecord

* integrate SANE support into cover editor

* use cdlabelgen as a preliminary solution to gnometoaster's cover editor
  and maybe when the "Gnome Printing System" couldn't be found.
  
* intelligent error handling (incl. suggestions how to solve a problem).
  The initial cause for this was a request from a user,demanding
  "some nice error message like 'got scsi generic in kernel/module loaded ?' "

* Bug report form as a button in Gnometoaster (email functionality ?!?)

* online help with a short description of the runtime vars available in 
  preferences setup
  
* free floating progress bar (so's it can be inserted into the main window
  if wanted) (Gnome-only,naturally)
  
* remove the 10 seconds pause before writing (a real hard one,it's hardcoded
  into cdrecord)
  
* select the track/file the mouse is over when the popup menu gets opened

* iso image writer,maybe one for dao and tao,where the tao image writer
  does,of course,write a separate image for every track in a
  specified directory. Maybe it could
  even create a script creating a cd from the images with a single command

* driver-based toc reading routines (e.g. cdda2wav as driver to get toc incl.
  cd text)
  
* is deleting files of the previous session possible by hiding them with the
  hide_joliet hide_rockridge options of mkisofs ?
  
* make selection list non-static,so's it can get as big as necessary.
  (currently,a constant defines the maximum selection size and the actual
  size should be compared against it to prevent buffer overflows)
  
* implement kind of a backup fs type piping "tar -chz /var/cdfs" to cdrecord
  (create archive,follow symlinks,pipe through gzip)
  CDs created this way can be restored typing "tar -xzf /dev/cdrom".
  
* multi-volume-backup ?!?

* optionally show command calls in recording terminal,

* sometimes preview_play refuses to work after a few tracks have been played

* create a minium amount of keyboard bindings,at least for the menubar

* make gnometoaster layout adapt to string lengths,no longer requiring
  the translators to be Artists as well
  
* add Phil Hagen's gtoaster icon to the distrib archive

* recording via network: design some network protocol enabling running
  gtoaster on a computer without cd writer and a small server app on
  a computer with writer,allowing transparent access of the writer
  exported by the cd writing server. We'd have to design both the server
  and the client (update: there's a thing called webcdwriter which can
  possibly be used for that purpose,it's got a server implementation in c++
  and a client in java)
  
* extend sanity check on startup
  
* respect a drive's state as a recorder when deciding wether to precache a
  track,even when the precaching flag has been changed manually.
  
* some open filedescriptor seems to block the cdroms eject button sometimes.

* option "delete sourcefiles",deleting all files written on cd from your
  harddrive
 
* sort tree view

* align text messages more nicely

* update tooltips (esp. destination section)

* add "upper dir" button 

* introduce a cancel button to the recording progress dialog

* Make fifo size of cdrecord editable 

* scroll directory tree to the position of the highlighted item

* introduce "mount" option to directory popups

* define an editable flag for tracks. This flag will be set true whenever
  a track is open. This can be used to gray out fsedit during the recording
  process for instance
  
* before recording starts,a "local" copy of the tracklist should be made,
  so's we can enable editing functions again (remove grab focus from all those
  copy dialogs)
  
* tracklists should get an editable flag as well

* build a script removing obsolete language entries

* the fillstate widget doesn't always react properly on theme changes

* write cdrdao compatible image files (I think the format is rather common in
  windows environments as well)
  
* multiple temp directories

* implement correct dvd size detection

* tooltips for destination section

* think about acceptable defaultcolors for the fillstate bar

* creating a directory and adding a dir to it via drag and drop doesn't
  show the "expand" symbol for the newly created dir 
  [Colin Marquardt <colin@marquardt-home.de>]
  
* implement uninstall dnd and use it in getdir.c

* videoCD support (vcdtools)

* implement progress box for adding files to fsedit (both linking and
  copying)

* display icon if multisession cd was imported and issue a warning if writing
  a secondary data track to a multisession disc without prior importing

* keep_alive for data sources while burning a cd.
  This will become specifically important in dao mode,when changes between
  tracks have to happen immediately.
  
* Napster Support !!

* display space allocated for the contents of a directory when right clicking
  and selecting properties.
  (display pie diagram in gnome version using gnome-canvas ?!?)

* enforce cdrom standard limitations: 
   - audio tracks have to have a certain minimum size (4 seconds I guess)

* create CORBA interface to make gnometoaster script-controllable
   - scripts will be stored in a plugin directory and they'll get the
     corba object identifier passed to them as their first commandline
     argument
   - if compiled with gnome-support,gtoaster will tell the Gnome GOAD 
     server about running instances of gnometoaster
   
* accept gnome-style shortcut hints in gtk menu builder

* support OGG Vorbis decoding (encoding should be implemented once mp3
  encoding gets implemented)

* check permissions of fsedit_destarea within the check handler 
  of preferences.c

* build a few generic failsafe handlers in the style of the fsedit_destarea
  check code 

* implement mask and unmask functions for quoted strings

* make amplification level of audiotracks adjustable

* implement "validity-bit" for all varman vars.
  that bit can then be used to fade out options that aren't available
  if a certain var hasn't been configured correctly.
  Perhaps even make auto-dependencies automatically setting a varmanwidget
  to gray if a certain condition is no met
  
* multisession and dao ???

* an attempt to describe what should happen in multirecorder mode:
   - every recording process doing the same job (multiplication of a 
     recording thread) will get their data from the same source.
     So we need one context for all processes of this kind
     and a list of "running backends"
   - all different recording processes will end up in a list of the 
     above-mentioned struct so's we can have both at the same time
     (given a sufficient amount of cd recorders ;-)) and of course
     scsi ones because ide will most likely kill all of your cds this way.
     a large array of cd recorders could, once the network protocol is
     implemented,even be spread across the network which would make this
     feature even more cool :-)

* to allow for multisession discs written with cdrdao we have to
  redefine datatracks to mode2form1 tracks which are being used 
  for multisession datatracks
     
* free pidwatch struct in record.c

* fillstate bar doesn't always redraw properly  

* force reimporting a cd after the second session has been recorded
  (or as a matter of fact if the cd gets changed while it is imported)
  
* after a disc at once recording session drive state doesn't seem to get
  updated any longer sometimes
  
* use hdparm to turn off that spindown timeout of all harddrives with mounted
  partitions during the recording process
  
* every track should get an extra cddb number and track number field.
  This way, we could restore cd title and track title out of m3u playlists
  etc. Perhaps it would be enough to build a track to cddb job id mapping

* play selected tracks when "play track" is pressed
  
* call redraw handler when expanding directories as gtk seems unable to 
  do this itself sometimes
  
* cdrecord is waiting for the user to press a key if it can't close 
  the cdrom tray automatically. This esp. happens when blanking a cd
  as cdrecord is attempting to update the cdrom's status by trying to reload
  the medium.
  However,cdrecord is waiting indefinitely in this case as the user doesn't
  have the opportunity to create a key event

* support checking mp3 files for errors before converting them

* invalidate precached data when the sources change (iso tracks)

* fix session together with writing the last track in tao mode.

* check available disc space and wether a track could be precached
  successfully

* introduce switch enabling/disabling cddb lookups.

* zero tracksizes can cause a division by zero error

* optionally display recording options in a dialog just before starting
  the recording process
  
* Gnometoaster can't read out data tracks of CD-Plus CDs

* read multisession discs properly, don't add the leadout to the last track
  of a session

* force temp path specified in preferences

* the BeOS port of Gtk+ seems to come along well ->
  we should definitely be wary of any developments in that direction cause
  the BeOS is a nice platform to play around with and a powerful cd recording
  application shouldn't be too a bad thing to exist (Maybe we can be there
  even before the port of StarOffice arrives :-))
  
* implement handler assuring that only one track encoder can be the default
  at a time
  
* request confirmation before terminating a recording process when the
  user clicks stop
  
* display message if recording process couldn't be terminated.

* fails to delete fsedit area if fsedit directory is a symlink

* sometimes quits with a segfault when deleting tracks from the tracklist

* claim() tracks that are dropped into fsedit as long as they haven't
  been copied.
  claim() tracks copied into the dnd buffer
  (those issues shouldn't do any harm as long as the user doesn't get the
  chance to destroy the source within the dnd event or while Gnometoaster
  is copying data. While copying, a modal message box is currently preventing
  the user from taking any measures that would destroy the last instance of
  a track so this is safe for now.

* crashes if stdfiletrack is in debugging mode

* freely adjustable pregaps for DAO

* separate recording backends out and let them communicate with record.c
  using some sort of call interface and backend_register(xxx)
  
* extend drive setup by backend+driver selection 
  (driver is a subsection of backend specifying the driver to be used
  by the backend, backends should provide a list to choose from)

* take care of stringsizes and max commandline parameters when using
  the cdrecord singlecall scheme. Best solve this by dynamically reallocating
  strings when necessary
  
* "fixate" switch only works for multi-call cdrecord mode

* dynmenu structure doesn't get freed when popup is aborted

* destination directory string doesn't get freed after "save as..."

* mountpoint detection doesn't work properly sometimes
  (delivering prepended spaces etc.)

* do not hardcompile dependency database but make this an xml or something
  file
  
* use threads when writing instead of tasks where available (to save memory)

* support for FreeBSD's Burncd.

* .cue/.bin support

* make vfs_unixtree_copy() stoppable

* update fillstate bar in the background

* recording options sanity check

* record CD title with cd text informations

* change release year in pic to 2001

* display 650 instead of 746

* limit file display

* remove fixate switch

* make fillstate size freely adjustable

* sometimes Gnometoaster will react weirdly if drives are removed from the 
  drivelist and later added again

* make multisession importer detect emty cds and refuse to import them

* sporadic crashes when new encoders are added

* resolve escaped characters manually in regexp function

* recorder buffer size

* reconsider 'drag and play' button

* fillstatebar code buggy

* online help 

* change update window size

* 'No Sound' will not restore play button and player active flag will
  stay set which voids and further recording processes
  
* cddb anonymization
