Difference between revisions of "Feature Wishlist (Setup)"

From MythTV Official Wiki
Jump to: navigation, search
(Added Provide processor feature-set (instruction-set-extensions) support via USE-flags)
(30 intermediate revisions by 12 users not shown)
Line 1: Line 1:
 +
{{Note box|One of the major plans for the 0.25 release is a rewritten setup procedure built into the backend web server. At such point, many of these issues may be addressed, or otherwise made irrelevent to the new utility.}}
 +
 
=== Initial setup ===
 
=== Initial setup ===
 +
* Export and Import of frontend settings. Perhaps into the backend, so all new frontends could take it as template in the initial setup.
 
* Simple request: Could there be name coherency among the setup commands (mythtv-setup, mythwelcome --setup, mythfrontend ("embedded" setup)? Or even better, can there be '''a single setup command''' that can setup all three sections?
 
* Simple request: Could there be name coherency among the setup commands (mythtv-setup, mythwelcome --setup, mythfrontend ("embedded" setup)? Or even better, can there be '''a single setup command''' that can setup all three sections?
 
* Provide visual feedback when external commands don't exist (e.g. when you type in a channel change command and mistype it).  Printing "WARNING: Command not found" in red right below the text box if the entered path or command is not found would be sufficient.
 
* Provide visual feedback when external commands don't exist (e.g. when you type in a channel change command and mistype it).  Printing "WARNING: Command not found" in red right below the text box if the entered path or command is not found would be sufficient.
* Use MythTV-Setup on your frontend machine to configure the backend. So every part wich mythtv-setup uses to detect hardware or other things need to be integrated into the backend. So that on a backend machine no X11 is needed to configure myth!
 
 
* Provide an option under setup that will gather system/mythtv config and info and allow a user to send an email to mythtv-users mail lists after careful prompting to ensure that new users can file useful bug reports or ask for help while including as much required information to provide a solution (Something similar to [http://freshmeat.net/projects/bug-buddy/ bug-buddy] )
 
* Provide an option under setup that will gather system/mythtv config and info and allow a user to send an email to mythtv-users mail lists after careful prompting to ensure that new users can file useful bug reports or ask for help while including as much required information to provide a solution (Something similar to [http://freshmeat.net/projects/bug-buddy/ bug-buddy] )
* suggestion that would require some v4l support... autodetect / enumerate all cards (and then of course allow deletion of individual sources via mythtv-setup).
+
* Provide autodetection of cards across card types, to provide a list of all available tuners to be added, rather than requiring user to know the type of card they want to add.
 
* When no channels are found during the channel scan it would be less confusing to have a message indicating this.
 
* When no channels are found during the channel scan it would be less confusing to have a message indicating this.
 
* Choose to avoid the tuning of the last tuned channel at the first startup of MythTV. If the last tuned channel was scrambled or fault the frontend hangs.
 
* Choose to avoid the tuning of the last tuned channel at the first startup of MythTV. If the last tuned channel was scrambled or fault the frontend hangs.
* mythtv-setup fail explicitly on (first) sql failure
 
* Current behaviour: In mythtv-setup, a channel scan in Input Connections sets the starting channel for the tuner used in the scan. No other tuners that use the same channel source are affected.  Proposal: When a starting channel is set (by a human or via a channel scan), also set the starting channel for all other tuners that use the same channel source. Only apply the enhancement to a tuner with no _defined_ starting channel or no _valid_ starting channel.
 
* If the above is not implemented please change the HOWTO to indicate that if you use the grabbers you MUST tell them which channels you have (if you don't know, tough!).
 
 
* Re-organization of configuration menus, hiding "advanced" features (or those which are normally fine when set to default), to assist an easier install for new users.
 
* Re-organization of configuration menus, hiding "advanced" features (or those which are normally fine when set to default), to assist an easier install for new users.
* setup and define network interface -- '''Huh? Why would you want to define your network interface through MythTV?'''--[[User:GBee|GBee]] 18:38, 22 March 2008 (UTC)
 
 
* Create a '''complete''' list of what libraries are required to compile the various options (ALSA, DTS-Passthrough, etc...)
 
* Create a '''complete''' list of what libraries are required to compile the various options (ALSA, DTS-Passthrough, etc...)
 
* Increase the limit on the combo box for time to wait for the next recording.  The current limit of 120 minutes is too short for some cases, and there is no apparent reason for such a limit.  Suggest increasing to at least 720, if not 1440 (24 hours).  The setting can be found in mythtv-setup/backendsettings.cpp, line 344.
 
* Increase the limit on the combo box for time to wait for the next recording.  The current limit of 120 minutes is too short for some cases, and there is no apparent reason for such a limit.  Suggest increasing to at least 720, if not 1440 (24 hours).  The setting can be found in mythtv-setup/backendsettings.cpp, line 344.
 +
* '''Gentoo Packaging''' ''Provide processor feature-set (instruction-set-extensions) support via USE-flags'': I try to build a Gentoo-based system using MyhtTV in a virtual-machine (VirtualBox) on an AMD Phenom II X6-based host. Later, I'll copy the system to the actual target which is a Celeron-M based on the PentiumIII (Coppermine). The target CPU only supports MMX and SSE. The host CPU supports much more (SSE2, SSE3, ...) and MythTV's build system (I use the ebuilds from  https://github.com/MythTV/packaging/tree/master/Gentoo) detects the CPU's features at compile-time. On the target, mythfrontend gets killed with SIGILL (Illegal instruction). Either MythTV should use run-time CPU detection (quite some work to implement) or the ebuilds should have USE-flags to hard-force the instruction set extensions that the target-processor supports (Not so much work, there are many ebuilds in the official tree that do so and since you have the configure-options anyways...)
  
 
=== Hardware support ===
 
=== Hardware support ===
 
* Support for additional tuners/cards on Mac OS X running Mythbackend.
 
* Support for additional tuners/cards on Mac OS X running Mythbackend.
* A solution to allow MythTV to watch and record encrypted digital cable broadcasts that the user has licensed.  This is an EXTREME pipe dream as it would require 1) cooperation, or at least noninterference, from the cable companies; 2) digital receiver cards that can accept CAMs from the cable provider; 3) volunteers to code the drivers.
 
:Note that this isn't *quite* as far fetched as it sounds.  It *may* prove possible to receive unencrypted (non-pay) digital cable channels in the US with the pcHDTV3000 card.  The encrypted ones would require a card compatible with a CableCard decryption card -- which cable companies *are* required to provide if you ask for one... but we're unlikely to see such a card ship *before* the July 1 2004 advent of the broadcast flag.  So support EFF in getting it thrown out.  :-) -- BayLink
 
::That was old commentary, but CableCard-capable HDTV tuner cards are actually expected in 2006 or early 07; see the news page. --[[User:Baylink|Baylink]] 05:50, 1 February 2006 (UTC)
 
::: Arstechnica wrote about news from CES that says we [http://arstechnica.com/news.ars/post/20060131-6081.html shouldn't get our hopes up].
 
* While I'm sure its already somewhat possible with DSLinux and lynx, why not create a Nintendo DS homebrew application that would allow you to interact with mythTV?  Imagine it, the remote like size of a DS lite, paired with the limitless possibilities for a gui interface with 2 screens and stylus/button control.  I can't imagine an easier way to interact wirelessly with mythTV from my couch.  Please make this happen, The DS homebrew community is thriving, it really wouldn't take much to slap a prototype together, and I'm sure things would move quickly after that.  Someone with the skills needs to do this.
 
 
* Menu navigation through mouse-wheel and possibility to assign actions to mouse buttons. --[[User:Matthias|Matt]] 12:09, 28 April 2007 (UTC) -- '''Already possible to some degree and 0.22 will have full mouse support, though it's more about supporting touchscreens.'''--[[User:GBee|GBee]] 18:41, 22 March 2008 (UTC)
 
* Menu navigation through mouse-wheel and possibility to assign actions to mouse buttons. --[[User:Matthias|Matt]] 12:09, 28 April 2007 (UTC) -- '''Already possible to some degree and 0.22 will have full mouse support, though it's more about supporting touchscreens.'''--[[User:GBee|GBee]] 18:41, 22 March 2008 (UTC)
 
* Support for [http://www.hdmi.org/pdf/whitepaper/DesigningCECintoYourNextHDMIProduct.pdf Consumer Electronics Control (CEC) bus] on HDMI interface equipped systems. --[[User:Rhulme|Rhulme]]
 
* Support for [http://www.hdmi.org/pdf/whitepaper/DesigningCECintoYourNextHDMIProduct.pdf Consumer Electronics Control (CEC) bus] on HDMI interface equipped systems. --[[User:Rhulme|Rhulme]]
 
* Support for the V4L radio device on Hauppauge cards as another TV channel (as per DVB radio channels) - tuned Radio can be played off /dev/video0, so extending the available inputs in the card set up should make this simple.
 
* Support for the V4L radio device on Hauppauge cards as another TV channel (as per DVB radio channels) - tuned Radio can be played off /dev/video0, so extending the available inputs in the card set up should make this simple.
 +
* Add to mythbackend setup menu item to reset dish motor (move to reference position).
  
 
=== Channel Management ===
 
=== Channel Management ===
Line 34: Line 29:
 
* Preview selected channel, to allow the user to easily choose what channel to keep and what channel to delete. This is expecially useful after a DVB-S receiver scan, which often discover thousands of channels.
 
* Preview selected channel, to allow the user to easily choose what channel to keep and what channel to delete. This is expecially useful after a DVB-S receiver scan, which often discover thousands of channels.
 
* DVB-T channel scanning here in Sweden (maybe the same setup elsewhere?) depending on the location you can have multiple transponders providing the same stream, but some of those transponders can be far off. The problem that we have here is that it some times chooses the weak transponder instead of the strong one. This could be solved the easy way or the hard way.  
 
* DVB-T channel scanning here in Sweden (maybe the same setup elsewhere?) depending on the location you can have multiple transponders providing the same stream, but some of those transponders can be far off. The problem that we have here is that it some times chooses the weak transponder instead of the strong one. This could be solved the easy way or the hard way.  
  1. Have a limit (user specified) of the lowest accepted signal-strength can be and ignore any transponders below that limit.
+
*# Have a limit (user specified) of the lowest accepted signal-strength can be and ignore any transponders below that limit.
 +
*# After a scan has been done display a list of "conflicting" transponders, and their signal-strength, and ask what transponders it should use.
 +
* Save the signal-strength/signal quality of each transponder to the database (update each time you try to tune to it) for easier lookup so it can be displayed in mythweb for easier maintenance of "good" channels. (Good for DVB-S)
 +
* Enable some type of "channel/transponder available from 22.00->07.00" that would pause any type of attempted recording from that channel/transponder. This is a problem for people that are on the edge on the reception area of some satellites and able to tune into them during the day but not the night etc. Could also be useful if you want to use a specified card for something else during specified hours every night.
 +
* At least display both physical channel number & subchannel number for digital channels in one of the channel editing channel lists. I can get a channel mapping between physical channel number_subchannel to Comcast channel numbers, and I can get a mapping of XMLTV IDs to Comcast channel numbers, but the channel numbers that MythTV chooses are random. While buried in the channel editor I can get the physical channel to mythTV channel number mapping, that does not help a whole lot when each physical channel can have as many as 50 subchannels, and the subchannel number is nowhere to be found without dumping the database.
  
 
=== Card Management ===
 
=== Card Management ===
* Combine video source and input connection into one entity. Video source is a basically Data Direct lineup, and input connections are inputs to the tuner. You can of course set up video source and input connection one to one by having multiple zap2It lineups, but why not just make it so by combining the two together? The fact that you can set up one video source and two input connections is pretty confusing.
 
 
For Example, my tuner has coax/tuner in and svideo in. I define one zip2it line-up of the unencrypted channels, and one with the encrypted. I create two videos sources connected to the two line-ups, and then two input connections, one for the tuner and no channel change script and connected to one the unencrypted lineup, and one with the svideo and channel change script for my blaster connected to the svideo and encrypted channels.
 
 
* Provide a way of deleting all transports for a given video source.
 
* Provide a way of deleting all transports for a given video source.
 
* Make myth use vendor ID's or something so it doesn't rely on /dev entries which can come up in any order on reboot.  (Note: This could be fixed by fiddling around with udev but it's a lot of work and there's very little documentation.  You also have to change the udev rules every time you add/remove a tuner from a different vendor).
 
* Make myth use vendor ID's or something so it doesn't rely on /dev entries which can come up in any order on reboot.  (Note: This could be fixed by fiddling around with udev but it's a lot of work and there's very little documentation.  You also have to change the udev rules every time you add/remove a tuner from a different vendor).
  
=== Card Groups ===
 
* The Hauppauge HVR-1300 Hybrid DVB-T/MPEG/Analogue card outputs a Linux TV DVB v3.x DVB-T stream, Hardware MPEG encoding and V4L frame grabber of Analogue TV/S-Video/Composite inputs.
 
 
The card works perfectly as a 'DVB DTV Capture Card (v3.x)'. Just load the cx88_dvb module. However, loading the cx88_blackbird module does not. The reason is that (possibly due to the internal wiring of the card) only DVB-T ''OR'' MPEG/analogue can be used, not both at the same time. MythTV sees this as three separate cards and tries to use them both at the same time, locking the other out. There are possibly more cards for which this behavior is the case.
 
Rather than trying to allow for this explicitly, introduce the notion of card groups. Only one card in any group can be used at a time. Any card that can be used simultaneously is assigned another group number. In the case of the HVR-1300, the DVB-T input is configured as a 'DVB DTV Capture Card (v3.x)' in group 1 and the hardware MPEG encoder input would be configured as /dev/v4l/video1 under 'MPEG Capture Card' group 1. If you really want to cook your CPU or if you have hardware MPEG on the motherboard, the analogue input can be configured as /dev/v4l/video0 under 'V4L Capture Card'. A second card would be configured in a similar manor but assigned to group 2 indicating that this card can be used concurrently with one of those in the other group.
 
 
=== Already Implemented ===
 
The following features have already been implemented, either in previous releases or head.
 
  
 +
=== Won't Implement ===
 +
The following features are either ones that should either be implemented as a 3rd party solution, are are something outside the capability or designed intent of MythTV.
 +
* While I'm sure its already somewhat possible with DSLinux and lynx, why not create a Nintendo DS homebrew application that would allow you to interact with mythTV?  Imagine it, the remote like size of a DS lite, paired with the limitless possibilities for a gui interface with 2 screens and stylus/button control.  I can't imagine an easier way to interact wirelessly with mythTV from my couch.  Please make this happen, The DS homebrew community is thriving, it really wouldn't take much to slap a prototype together, and I'm sure things would move quickly after that.  Someone with the skills needs to do this.
 +
** An initial version of this has already been done, take a look at this [http://grizzly.thewaffleiron.net/mythremote/ MythRemote for NDS]
 +
* Front-end setup option to mythvideo allowing user to select whether or not changing to a higher parent control level includes all lower levels in the display or not.  For example, currently parent control level 3 displays all videos from levels 1-3 vs only those set to parent control level 3.  This eases navigation when a large number of videos is present.  I've hard coded this in videofilters.cpp but don't have the skill to code this as a user selectable option into the setup screens.
 +
** Parental controls are only intended to restrict access to certain content, not as an organization tool. If you need something to speed navigation through a large library, use the Filter through the 'm' menu. The Genre and Category fields already exist to do exactly what you want. [[User:Wagnerrp|wagnerrp]] 00:44, 5 November 2009 (UTC)
 +
* During setup use a font that allow's you to tell the difference between 0 and O and I and l at least for the mysql password field.
 +
** The font is defined by the theme, not mythtv-setup.
 +
* mythtv-setup fail explicitly on (first) sql failure
 +
:: mythtv-setup application is slated for removal
 +
* Front-end setup to set screen dimensions.  If a TV/monitor reports the wrong dimensions via EDID the only way to fix this currently is to edit xorg.conf to add a DisplaySize entry.  Requiring users to edit xorg.conf is cruel & unusual punishment.  Include a couple of boxes on the Setup>Appearance menu defaulting to 0 for X & Y dimensions.  If zero accept what xorg says, if non-zero take these dimensions when scaling TV display.
 +
:: scaling is determined by the theme, and physical display size set in X has no effect
 +
* Combine video source and input connection into one entity. Video source is a basically Data Direct lineup, and input connections are inputs to the tuner. You can of course set up video source and input connection one to one by having multiple zap2It lineups, but why not just make it so by combining the two together? The fact that you can set up one video source and two input connections is pretty confusing.
 +
:: The proposal would increase processing, disk, database, and bandwidth load, for both user and provider, on multi-tuner systems, based off the assumption the user cannot grasp a fairly simple concept. The two may be renamed to be more explicit to the user, and the internal workings may be hidden from the user, but the behavior will remain.
  
[[Category:Developer Documentation]]
+
[[Category:Wishlist]]

Revision as of 17:22, 5 March 2012

Important.png Note: One of the major plans for the 0.25 release is a rewritten setup procedure built into the backend web server. At such point, many of these issues may be addressed, or otherwise made irrelevent to the new utility.

Initial setup

  • Export and Import of frontend settings. Perhaps into the backend, so all new frontends could take it as template in the initial setup.
  • Simple request: Could there be name coherency among the setup commands (mythtv-setup, mythwelcome --setup, mythfrontend ("embedded" setup)? Or even better, can there be a single setup command that can setup all three sections?
  • Provide visual feedback when external commands don't exist (e.g. when you type in a channel change command and mistype it). Printing "WARNING: Command not found" in red right below the text box if the entered path or command is not found would be sufficient.
  • Provide an option under setup that will gather system/mythtv config and info and allow a user to send an email to mythtv-users mail lists after careful prompting to ensure that new users can file useful bug reports or ask for help while including as much required information to provide a solution (Something similar to bug-buddy )
  • Provide autodetection of cards across card types, to provide a list of all available tuners to be added, rather than requiring user to know the type of card they want to add.
  • When no channels are found during the channel scan it would be less confusing to have a message indicating this.
  • Choose to avoid the tuning of the last tuned channel at the first startup of MythTV. If the last tuned channel was scrambled or fault the frontend hangs.
  • Re-organization of configuration menus, hiding "advanced" features (or those which are normally fine when set to default), to assist an easier install for new users.
  • Create a complete list of what libraries are required to compile the various options (ALSA, DTS-Passthrough, etc...)
  • Increase the limit on the combo box for time to wait for the next recording. The current limit of 120 minutes is too short for some cases, and there is no apparent reason for such a limit. Suggest increasing to at least 720, if not 1440 (24 hours). The setting can be found in mythtv-setup/backendsettings.cpp, line 344.
  • Gentoo Packaging Provide processor feature-set (instruction-set-extensions) support via USE-flags: I try to build a Gentoo-based system using MyhtTV in a virtual-machine (VirtualBox) on an AMD Phenom II X6-based host. Later, I'll copy the system to the actual target which is a Celeron-M based on the PentiumIII (Coppermine). The target CPU only supports MMX and SSE. The host CPU supports much more (SSE2, SSE3, ...) and MythTV's build system (I use the ebuilds from https://github.com/MythTV/packaging/tree/master/Gentoo) detects the CPU's features at compile-time. On the target, mythfrontend gets killed with SIGILL (Illegal instruction). Either MythTV should use run-time CPU detection (quite some work to implement) or the ebuilds should have USE-flags to hard-force the instruction set extensions that the target-processor supports (Not so much work, there are many ebuilds in the official tree that do so and since you have the configure-options anyways...)

Hardware support

  • Support for additional tuners/cards on Mac OS X running Mythbackend.
  • Menu navigation through mouse-wheel and possibility to assign actions to mouse buttons. --Matt 12:09, 28 April 2007 (UTC) -- Already possible to some degree and 0.22 will have full mouse support, though it's more about supporting touchscreens.--GBee 18:41, 22 March 2008 (UTC)
  • Support for Consumer Electronics Control (CEC) bus on HDMI interface equipped systems. --Rhulme
  • Support for the V4L radio device on Hauppauge cards as another TV channel (as per DVB radio channels) - tuned Radio can be played off /dev/video0, so extending the available inputs in the card set up should make this simple.
  • Add to mythbackend setup menu item to reset dish motor (move to reference position).

Channel Management

  • Editing more than one channel at the time for example to set them to visible should be possible
  • Sort/select channels by missing XMLTV ID
  • Option to tag channels as belonging to a group. For example, Premiere channels in Germany, Digital+ channels in Spain (all being on one Satellite). Enable filtering by these groups.
  • Modern way to add channel icons (selection box, or by naming scheme like for example chanid.png) -- See #3334 -- Matthew Wire
  • Reordering the channels to a preferred viewing order without changing the channel number (as it currently breaks the recording schedules if you do so)
  • Preview selected channel, to allow the user to easily choose what channel to keep and what channel to delete. This is expecially useful after a DVB-S receiver scan, which often discover thousands of channels.
  • DVB-T channel scanning here in Sweden (maybe the same setup elsewhere?) depending on the location you can have multiple transponders providing the same stream, but some of those transponders can be far off. The problem that we have here is that it some times chooses the weak transponder instead of the strong one. This could be solved the easy way or the hard way.
    1. Have a limit (user specified) of the lowest accepted signal-strength can be and ignore any transponders below that limit.
    2. After a scan has been done display a list of "conflicting" transponders, and their signal-strength, and ask what transponders it should use.
  • Save the signal-strength/signal quality of each transponder to the database (update each time you try to tune to it) for easier lookup so it can be displayed in mythweb for easier maintenance of "good" channels. (Good for DVB-S)
  • Enable some type of "channel/transponder available from 22.00->07.00" that would pause any type of attempted recording from that channel/transponder. This is a problem for people that are on the edge on the reception area of some satellites and able to tune into them during the day but not the night etc. Could also be useful if you want to use a specified card for something else during specified hours every night.
  • At least display both physical channel number & subchannel number for digital channels in one of the channel editing channel lists. I can get a channel mapping between physical channel number_subchannel to Comcast channel numbers, and I can get a mapping of XMLTV IDs to Comcast channel numbers, but the channel numbers that MythTV chooses are random. While buried in the channel editor I can get the physical channel to mythTV channel number mapping, that does not help a whole lot when each physical channel can have as many as 50 subchannels, and the subchannel number is nowhere to be found without dumping the database.

Card Management

  • Provide a way of deleting all transports for a given video source.
  • Make myth use vendor ID's or something so it doesn't rely on /dev entries which can come up in any order on reboot. (Note: This could be fixed by fiddling around with udev but it's a lot of work and there's very little documentation. You also have to change the udev rules every time you add/remove a tuner from a different vendor).


Won't Implement

The following features are either ones that should either be implemented as a 3rd party solution, are are something outside the capability or designed intent of MythTV.

  • While I'm sure its already somewhat possible with DSLinux and lynx, why not create a Nintendo DS homebrew application that would allow you to interact with mythTV? Imagine it, the remote like size of a DS lite, paired with the limitless possibilities for a gui interface with 2 screens and stylus/button control. I can't imagine an easier way to interact wirelessly with mythTV from my couch. Please make this happen, The DS homebrew community is thriving, it really wouldn't take much to slap a prototype together, and I'm sure things would move quickly after that. Someone with the skills needs to do this.
    • An initial version of this has already been done, take a look at this MythRemote for NDS
  • Front-end setup option to mythvideo allowing user to select whether or not changing to a higher parent control level includes all lower levels in the display or not. For example, currently parent control level 3 displays all videos from levels 1-3 vs only those set to parent control level 3. This eases navigation when a large number of videos is present. I've hard coded this in videofilters.cpp but don't have the skill to code this as a user selectable option into the setup screens.
    • Parental controls are only intended to restrict access to certain content, not as an organization tool. If you need something to speed navigation through a large library, use the Filter through the 'm' menu. The Genre and Category fields already exist to do exactly what you want. wagnerrp 00:44, 5 November 2009 (UTC)
  • During setup use a font that allow's you to tell the difference between 0 and O and I and l at least for the mysql password field.
    • The font is defined by the theme, not mythtv-setup.
  • mythtv-setup fail explicitly on (first) sql failure
mythtv-setup application is slated for removal
  • Front-end setup to set screen dimensions. If a TV/monitor reports the wrong dimensions via EDID the only way to fix this currently is to edit xorg.conf to add a DisplaySize entry. Requiring users to edit xorg.conf is cruel & unusual punishment. Include a couple of boxes on the Setup>Appearance menu defaulting to 0 for X & Y dimensions. If zero accept what xorg says, if non-zero take these dimensions when scaling TV display.
scaling is determined by the theme, and physical display size set in X has no effect
  • Combine video source and input connection into one entity. Video source is a basically Data Direct lineup, and input connections are inputs to the tuner. You can of course set up video source and input connection one to one by having multiple zap2It lineups, but why not just make it so by combining the two together? The fact that you can set up one video source and two input connections is pretty confusing.
The proposal would increase processing, disk, database, and bandwidth load, for both user and provider, on multi-tuner systems, based off the assumption the user cannot grasp a fairly simple concept. The two may be renamed to be more explicit to the user, and the internal workings may be hidden from the user, but the behavior will remain.