53

That isn't at all what I was picturing. I was thinking something actually integrated into dolphin, as opposed to what amount to a K3B window just stuck inside dolphin. If we are going that route we might as well just us K3B.

In the end, everything we need to use dolphin as a regular file burner is there. There is a free space meter at the bottom, actions can be assigned to right-click, we can rename stuff. No need to embed a K3B inside dolphin.

Hey, "just stuck in" is what I could do in gimp without spending all day on it.

The point is that the set of controls and all the interface components from k3b should be reused as far as possible IMHO.

Cheers,

andre_orwell wrote:This kind of thing was what I was imagining (forgive the quick and dirty image cut and paste work) - k3b appears within dolphin.

But that would have the same limitations that k3b have (namelly no icon view).

Here is a rough version of what I was expecting:This is the base level of the kio slave. It shows a list of CD/DVD/HD-DVD/Blu-ray drives available on your system, separated by whether they have discs or not and maybe what sort of drive they are. If there is a disc in the drive, you can give the disc a name the same way you give any file or folder a name. On right-clicking on the disc you would get options to eject the disc without burning, burning the disc, renaming the disc, and perhaps some additional options like opening the disc in K3B, changing the disc properties, and so on. As you can see from the menu on the right, you also get a couple of options when clicking on the disc in the places bar.Here is what you would see if you opened the disc at the top. You can see that it is just like any other folder, except the space bar at the bottom tells you what sort of disc it is (so in this case it shows it as a CD). This is similar to how K3B fills up the CD space meter until it gets bigger than a CD, then switches to DVD-5 mode, then DVD-9 mode. Otherwise everything is exactly what you are used to in Dolphin:

For anything else use K3B. If one of the files has an incompatible name, when you tell it to burn it should pop up a message to let you rename it or have it automatically rename all incompatible files.

I know I didn't get the CD capacity right, it just wasn't worth the effort.

In the end, my opinion is that if people want an advanced, full-featured CD/DVD burner with lots of options and features, they should use K3B. If they just want to drop in a few files and be done with it, they should be able to do that in Dolphin. Dolphin's CD burner should not worry about things like encoding, CD and DVD standards, multi-session, etc. It should just provide maximum compatibility bare-bones functions. I also don't think it should re-use any K3B UI elements, everything should be done within the normal Dolphin interface so people who are familiar with dolphin can use it without needing to learn anything or make any adjustments. It should be as seamless as possible.

^ I reckon it could be even more basic: just have the CD behave like any other file/folder, with you dragging and dropping stuff to and from it, with the exception that files aren't burned to it straight away. Then provide a small button at the bottom left to burn, like the, "close" button that appears when there's an error of some sort:
See here (of course, the button would be more obvious that it's a button...).

This wish looks a lot like this issue on KDE Bugzilla: https://bugs.kde.org/show_bug.cgi?id=187166

Madman wrote:^ I reckon it could be even more basic: just have the CD behave like any other file/folder, with you dragging and dropping stuff to and from it, with the exception that files aren't burned to it straight away. Then provide a small button at the bottom left to burn, like the, "close" button that appears when there's an error of some sort:
See here (of course, the button would be more obvious that it's a button...).

You would still need a kio slave, and the kio slave would need a root. The first image is just a picture of the root. Each CD drive is just a folder in the root. I also think it is important to provide an easy way to rename the disc. Burning should just burn it, I don't think it should go through a bunch of configuration options like in windows.

TheBlackCat wrote:You would still need a kio slave, and the kio slave would need a root. The first image is just a picture of the root.

Aah, I see. Still, the user doesn't necessarily have to see the root - when the Kioslave detects new CDs, it could just slap them all in the side-bar.

TheBlackCat wrote:Each CD drive is just a folder in the root. I also think it is important to provide an easy way to rename the disc. Burning should just burn it, I don't think it should go through a bunch of configuration options like in windows.

Perhaps the Kioslave could store its data in ~/.kde, and allow the renaming of not-yet-burned CDs directly - like folders - then burn that name to the CD when you click, "burn". I was aiming for a, "zero-configuration-dialogue" approach as well. There's a reason it's called Windows.

Madman wrote:Aah, I see. Still, the user doesn't necessarily have to see the root - when the Kioslave detects new CDs, it could just slap them all in the side-bar.

It would, and the second picture is what you would see if you clicked on the icon on the side bar. The first picture would be what you would see if you moved up one directory, or opened the kio slave from the address bar.

Madman wrote:Perhaps the Kioslave could store its data in ~/.kde, and allow the renaming of not-yet-burned CDs directly - like folders - then burn that name to the CD when you click, "burn". I was aiming for a, "zero-configuration-dialogue" approach as well. There's a reason it's called Windows.

I'm not sure that is necessary, the name could just be stored in memory.

Still, I don't like the idea of placing the burn command in a context menu - that requires the user to actually know that it won't just burn as they're doing it or before you eject, and that you need to right-click to actually start burning. That's why I chose to show a button at the bottom of the main view - so that the user knows they HAVE to click that button, or go to the context menu, to write those files to the CD.

The operating system should be able to lock the disc. If the user tries to eject, it could ask whether they really want to eject or if they want to burn the disc. That is not to say that I think the button is a bad idea, it looks fairly obvious but unobtrusive. I am not sure how easy it would be to implement using the existing kio slave system, though. If they implement the actions panel like I suggested the burn option could go there.

This idea is a dupe of brainstorm.php#idea39314