This is a short todo list for ideas and suggestions received from people
using the software. 


TODO/WISHLIST

* For those of us in the US that are hooked on
  channel numbers, you could either put channels in numeric order to
  start, or have an option to sort them (e.g. could sort by numeric order
  or channel name).  
	by Ryan Hayle <hackel@***>
	by Bearcat M. Sandor
	Secondary target for spring 07.

* GShowTV is not quite nice with a big set of channels. Channel grouping
  should be implemented. 
	by pvakevai
	Tertiary target for spring 07.

* The list window could show the programs of a set of channels instead of
  programs of one channel. (ala http://www.telkku.com  et al) Depends on
  channel groups. 
	by pvakevai
	Tertiary target for spring 07.

* Write a proper help and other documentation.
	by <pvakevai>

* Launch TV viewer directly from gshowtv.
	by <pvakevai>

* A Now'n'Next view.
	by <pvakevai>

* Possibility to lauch tv_grab_* from GShowTV manually. 
	by <pizbit@***>
	- Somehow the task of tv_grab running has to be implemented. For the
	  users the instruction, "set up a cronjob", is a bit too hard. Some
	  management for this task is needed. <pvakevai>
	- As the druid already provides us a single interface to running the
	  tv_grab command, it shouldn't prove too taxing to provide another
	  launcher to manually launch the tv_grab command. It could be
	  configurable and by default put to be the same as the xmltv-druid uses.

* For the date's show list it should be definable from which time the list
  starts and where it ends, e.g. it should be possible to say that show
  today's tv-shows starting from 4:00 AM and show up to 2:00 AM tomorrow.
	by <pvakevai>

* Automatically issue record command for favourite shows. 
	by <pizbit@***>
	- I've written a small script that performs this function outside of 
	  gshowtv. It utilizes gshowtv's configuration and data files, and
	  is run via cron. If anyone is interested, I can share this on
	  request.

* Timezone adjustment.
	by <sdiconov@***>

DONE SUGGESTIONS

* Refactor the code to a multiple file modules. Current scheme to keep the
  whole app in one single file is starting to reach it's limits. Implementing
  new features is hard, finding bugs is hard, testing is hard. Plus the code
  starts to be brittle. 
	by pvakevai
	Primary target for spring 07.

* The empty xmlfile bug should be fixed as now gshowtv keeps trying to
  reload the file each minute. 
	by many sources

* Total pimpup of the favourites system.
	by many sources

* Favourites should be editable, so that you don't have to delete the
  existing and add a new one. Also colouring should be possible to remove.
	by <pvakevai>

* Reminders should be shown using the notification protocol (DBUS)
  via notify-send (due to lack of a decent dbus/libnotify perl api)
	by <pvakevai>
	- Implemented

* The current date view shouldn't be in the toolbar.
	by Richard Spindler <oracle2025@***>
	- The date is now placed to the window title as per Gnome HIG. Also
	  the toolbar style setting is removed, and the system wide setting
	  is used. (By not having the toolbar_style set in the glade file.)
	  <pvakevai>

* The grid is a static element and when the xmltv data changes, ALL
  places where the data is shown, should also change. So either the grid
  has to be non-static, or the existing grids need to be destroyed when
  the data changes. 
	by <pvakevai>
	- The grids are now destroyed always at midnight and the current
	  grid updated.

* Support for multiple XMLTV files.
	by <sdiconov@***>
	- Now it's possible to combine several xmltv files into gshowtv
	  format. You have to do a little handwork to get it done, as the ui
	  doesn't directly support this. This can be accomplished by 
	  gshowtv -p xmltvfile1 xmltvfile2 xmltvfile3 ...
	by <pvakevai>

* Get rid of the thread. Use instead a separate program to parse the
  datafile on the background and then use Data::Dumper and Gtk2::Helper
  to read in the parsed XMLTV file. It goes *slightly* faster and 
  is more like Gtk2 programming. Further benefits:
	- The datastructure can be serialized.
	- Serialized data doesn't have to be reparsed, the startup is *slightly*
	  faster. (eval -> 1/10 xml parsing)
	- Each day serialized to it's own file, increases startup speed. (Is
	  today serialized, get it if yes, then serialize the whole xmltv 
	  file again, and reload.)
	- Serialized data structure allows background processing of heavier
	  tasks like finding the favourites, AND updating them dynamically.)
	by <pvakevai>

* Gridmode listings.
	by <tony_clegg@***>

* Favourites alert message. The app should display a notification dialog
  when the favourite is about to start.
	by <pvakevai>

* The startup could still be a bit faster, at least the main window with
  channels should pop up soon. Maybe the XMLTVParser could notify each new
  date being parsed?
	by <pvakevai>
	- After loading the first day of XMLTV data, display the main
	  window. This speeds up the startup by a big notch.

* If the recorded file doesn't exist in the file system, remove the entry for
  it too.
	by <pvakevai>
	- Don't remove the spool file for this show, just don't show 
	  the entry in the list. 

* A Configuration druid for the xmltv tv_grab program. The druid should be
  completely independent of gshowtv. (Perhaps used by other apps as well)
	by <pvakevai>
	- The druid is not an integral part of gshowtv, it's its own
	  application called xmltv-druid and it can be used to select/configure/setup
	  cron job for a tv grabber.

* Internally the program shouldn't be dependant on the gnome libraries as
  they have been deprecated by Gnome team. (at least most of them.) The
  design of gshowtv should reflect that.
	by <pvakevai>
	- gshowtv is now only dependant on gnome-help and gnome-open
	  commands. <pvakevai>

* Current date display is horrific. The dates and times should be displayed
  more to users preferences, e.g. dates should be "08 May" and "8.5."
  and times either in 24H format or 12H format. Only the recorded view may
  contain year info.
	by <pvakevai>

* The favourite/recorded shows should have some color coding, that the user
  can easier see what have been marked. Also the favourites shows should
  have some color coding, so that very interesting shows would be shown as
  such. <pizbit@****>

* Default window size should be less than 800x600. 
  by Eugenia Loli-Queru <eloli@***>
	- Make the default size small, but also make gshowtv to remember
	  the exit time window size, that will not annoy those who have
	  bigger screen. <pvakevai>

* New set of images: A language independant default channel image plus menu
  image courtesy by <sdiconov@***>

* Fully localizable.

* Channel images should be managed by GShowTV internally, an image picker
  should be included with the channel editor.
	by <pvakevai>
  	Implemented to fetch all channel images defined in the XMLTV file.

* GShowTV should react to time passing. It should refresh the lists when
  changes occur. These changes are: 
	1. the xmltv file get's updated, update all lists.
	2. In the recording list a tv show ends, update recording list.
	3. In the favourites list a tv show ends, update favourites list.
	by <pvakevai>, and others (Not implemented)

* Recorded filenames should be possible to open even if they contain spaces
  or other troublesome characters.
	by <pizbit@***>
	- This should now be possible. Anyway currently the new PVR
	  interface totally isolates gshowtv from the task of opening up
	  files.
	by <pvakevai>
	
FAILED SUGGESTIONS

* Move the xmltv file getter from cronjob to be a part of gshowtv. Create
  a configuration option/druid to select the tv_grab:er and a channel list
  from that druid. 
  by <pvakevai>
	- Will require some threading in the gshowtv, and will slow the app
	  startup time. Will have to be careful with how the xml file is
	  fetched from the net, so that it will not appear too slow to the
	  user. Try: first show some annoyance window: "Loading TV Schedule
	  information..", load one the first day and load the rest with 
	  a background process. Check if todays list is already loaded, if
	  so don't reload! <pvakevai>
  - The running of a tv_grab_* takes a lot of time even with my company's
    broadband connection. Even for 1 day with a relatively few channels the task
    is heavy. (I.e. not just a few seconds) Therefore for the user experience 
    I'm still convinced that the task of tv_grab should be run via cron. <pvakevai>