[vlc-devel] [vlc-commits] Qt: menu: move advanced open.

[Rémi Denis-Courmont]

Le dimanche 27 mars 2011 00:32:19 Pierre Ynard, vous avez écrit :
> > > If you remove their open panels, how are you going to allow opening
> > > them with advanced inputs options?
> > 
> > What advanced options?
> 
> Caching.

I am not convinced that we need this option at all. The cache size will 
automatically expand anyway.

> Input slaves.

How many people use this, outside of the capture case? More-often-than-not, 
input slaves won't work either because the slave does not implement slave 
mode, or because different incompatible time stamps are involved.

OK, for Convert, you might need some fancy option like start-time, chapter, 
etc, but they're not needed normal open.

> > Title selection is HARMFUL here, as already exemplified in my previous
> > mail. For navigation, we have the navigation menu. [...] All that
> > stuff is aimed at automation, not at UI. For the third time, it is
> > confusing normal users rather than helping. Why oh why do they need to
> > know whether a disc is a DVD or a CDDA??

Point conveniently ignored for the second time.

> > Why does DVD stop after one chapter if they selected a chapter?

Another point conveniently ignored for the second time.

> > This all makes sense in a .bat or
> > a shell script that runs VLC unattended, not in the UI.

> Command-line invocation != automation.

You can use the CLI for manual use, especially if you are a developer. I do 
that almost daily. I never said we should remove CLI features.
You can use the advanced dialog for Convert. But Convert has menu item of its 
own already in any case.

> There are people who want to do
> something advanced on a one-time basis, and who can't/won't use the
> command line, that's what we have wizards for. I'd also say that people
> who want to do conversion probably wish it was automated, but will still
> use the conversion wizard.
> 
> > That is evident. We cannot enumerate all network locations, and we
> > should not enumerate all local files (due to I/O). However we can
> > enumerate all discs, and we can probably enumerate all capture devices.
> 
> I agree that we need a panel to open arbitrary locations, and that
> fields to type out devices that could be enumerated in a list instead
> are retarded. Yet, these could be enumerated in a drop-down the open
> panel, just like the dshow panel does. Sure, it would make the UI depend
> on libudev or whatever, but so?

There are a number of problems with this:

1/ Detection needs to be in SD (or whatever) to support LibVLC and other 
interfaces. So if it is dumb to replicate it in Qt4.

2/ Drop down lists cannot cope with hotplug and dynamically changing list. 
They should only be used when there really is no choice. So if the user opens 
the dialog before the system has detected the device, FAIL.

3/ Drop down lists cannot deal with long lists and can barely deal with trees 
so forget about the network services or a TV channels list there.

> IOW, we have two overlapping ways of opening media: dialog based, and
> playlist based. And I fail to see your arguments for the latter rather
> than fixing the former, except that the latter is currently working
> better.

I fail to see your argument for sticking with a broken user-unfriendly thing 
when we already have the user-friendly thing working. If you want to embed SD 
within the open dialog, go ahead. But don't make me responsible for your 
choices. What I'm seeing today is, the SD work and the dialog does not. Yet 
the dialog is very visible, and the SD are hidden.

-- 
Rémi Denis-Courmont
Looking for a job: http://www.remlab.info/
http://fi.linkedin.com/in/remidenis