After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 554201 - Project size graph in status bar
Project size graph in status bar
Status: RESOLVED FIXED
Product: brasero
Classification: Applications
Component: general
0.8.1
Other Linux
: Normal normal
: 0.8
Assigned To: Brasero maintainer(s)
Brasero maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2008-09-28 17:01 UTC by Michael Monreal
Modified: 2009-07-13 15:51 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Mockup (30.51 KB, image/png)
2008-09-28 17:01 UTC, Michael Monreal
Details
scheenshot 1 (77.23 KB, image/png)
2009-06-01 12:51 UTC, Philippe Rouquier
Details
Screenshot 2 (69.22 KB, image/png)
2009-06-01 12:53 UTC, Philippe Rouquier
Details
Screenshot 3 (85.76 KB, image/png)
2009-06-01 12:55 UTC, Philippe Rouquier
Details
Screenshot 4 (229.92 KB, image/png)
2009-06-01 12:56 UTC, Philippe Rouquier
Details
Screenshot 5 (78.58 KB, image/png)
2009-06-01 12:57 UTC, Philippe Rouquier
Details
Second attempt (93.18 KB, image/png)
2009-06-03 13:28 UTC, Philippe Rouquier
Details
Screenshot + Comments (11.32 KB, image/png)
2009-06-27 14:08 UTC, Michael Monreal
Details

Description Michael Monreal 2008-09-28 17:01:16 UTC
In trunk, the project size graph is gone. This makes the UI look simpler, but at the same time the graph was very nice to give a general idea on how much space is left on a disc.

What about adding one of the simple graphs (like in the "Space" column) to the status bar if a recordable medium is inserted? Also, displaying "x of y MiB" would be nice (instead of "x MiB"). If no recordable medium is inserted, the current look is fine.
Comment 1 Michael Monreal 2008-09-28 17:01:37 UTC
Created attachment 119538 [details]
Mockup
Comment 2 Luis Medinas 2008-09-28 18:53:12 UTC
Michael i already give this suggestion to Philippe but something like the Banshee one for ipods. I think it's a little more impressive and easier to see.
Comment 3 Michael Monreal 2008-09-28 19:34:32 UTC
Yeah the banshee graph is awesome. I've seen a number of users dropping into the irc chan just to ask "how can I get this graph" and they seem to be disappointed if we tell them that it's not meant for the main library :)
Comment 4 Philippe Rouquier 2008-10-01 11:59:17 UTC
I think banshee bar is great but integrating it in brasero raises one issue, its size. It's really big and it won't fit in the statusbar. Now in the project it would be also too big and would remove space for the treeview which is IMO the most important part of all.

Instead of that, I intend to _try_ drawing a small CD on the tree background, slightly shaded so as to keep it unobtrusive. I have no working code and setting a background for an entire treeview is not an easy and straight forward task so I don't know if it works. But that would be the best if I can succeed.

Now there is also the issue of when displaying such a thing:
- when multisession discs are loaded: no doubt
- when a writable disc is loaded: sure why not

but (though it's not very common except for burner app developpers) what if you have many burners with a writable disc inside??
Comment 5 Ivan Zlatev 2008-10-05 15:55:08 UTC
CC myself.
Comment 6 Luca Ferretti 2009-04-17 20:31:31 UTC
Could we target this bug for 2.27 release?

It seems that users didn't like feature regression.
Comment 7 Matteo Drera 2009-04-17 21:11:23 UTC
(In reply to comment #6)
> Could we target this bug for 2.27 release?
> 
> It seems that users didn't like feature regression.
> 

I confirm.
It's really (really) hard to understand total_project_size / disk_usage.
Comment 8 Philippe Rouquier 2009-05-07 11:30:57 UTC
@Luca:
Now that I have finished splitting brasero between the application and the library, I think we can think of something.

Where I am ATM:
I gave up trying to show this in the background of the treeview. That's simply no doable.

A right model for a bar (should we add one) would be the banshee's one.

Now the real problem is this: when we don't have an appendable disc on which we want to burn an additional session, what would be the point of such a bar? It's pretty useless as the user hasn't chosen a disc yet and there is not total size at this point for the disc, just the size of all data.

I think I came up with something that could work. The bar would be like this (again, with banshee's bar's polish):
______________________________________________________________________________
_______________________________  [Text for the data size]                     |
______________________________________________________________________________|
             |            |                              |                  |
           CD (650 MiB)  CD (700 MiB)                   DVD (4.1 GiB)    DVD dual layer ...

That would help the user to know on which media type his/her data would fit and make the bar a bit more useful.
Additionnally, what could be possible would be to write underneath (on the last line next to or replacing "CD (650 MiB)") all discs that have been detected by brasero.

As for the multisession case, on the disc that would have been picked up by the user, the bar would be shown with green, orange and red colour as it used to be the case.

What I'm also concerned about is the size this thing is going to eat and the location that it should be given.

Ideas are welcome.

Comment 9 Luca Ferretti 2009-05-10 09:48:28 UTC
(In reply to comment #8)
> @Luca:
> 
> A right model for a bar (should we add one) would be the banshee's one.

Rhythmbox people are working on a "fill bar" widget too. In bug #558576 there is an initial and incomplete port of banshee's SegmentedBar to C. Maybe we really need a GtkFill widget in GTK+
 
> That would help the user to know on which media type his/her data would fit and
> make the bar a bit more useful.

Just a doubt: using only one bar for all media size, we will end to provide less "feedback" for small media (such as CD compared to DVD DL), isn't it?

At least if the bar is proportionally related to media size, I suppose. I'll try to draw it in "actual" width.

> What I'm also concerned about is the size this thing is going to eat and the
> location that it should be given.
> 
> Ideas are welcome.
> 

I suppose we have two cases:
 a) the bar is showing the used/available space on inserted media
 b) no inserted media

The fist case should be trivial: the bar is something like

 [##############___________] DVD - 4.7GB
   ^- filled       ^- empty

Brasero knows the max available space, all available bar width can be used. Coul be good use different colors to show different file types (not really needed, but cool, people loves cool stuff).

About case b, I've no good idea... Maybe the best is try to implement something like your proposal and wait for user feedback. Meanwhile, checking other burning apps could be good :)
Comment 10 Philippe Rouquier 2009-06-01 12:50:06 UTC
I've given a lot of thoughts to this issue lately and I wanted to have something to show before exposing it. See the following screenshots.

This is basically a new UI:
- no more burn option dialog after hitting burn button (saves one click)
- the progress bar is contained in the medium chooser combo which makes a lot more sense and solves the issue raised by this bug

Notes: only one expander can be opened at a time so as not to make the dialog ugly and too big.

This is incomplete at the time and not working properly yet, except perhaps for the data project, (only in my private tree) and subject to changes.

Please I saw there were many people interested in this. Let me know what you think about that new layout.
Comment 11 Philippe Rouquier 2009-06-01 12:51:29 UTC
Created attachment 135725 [details]
scheenshot 1
Comment 12 Philippe Rouquier 2009-06-01 12:53:45 UTC
Created attachment 135726 [details]
Screenshot 2
Comment 13 Philippe Rouquier 2009-06-01 12:55:41 UTC
Created attachment 135727 [details]
Screenshot 3
Comment 14 Philippe Rouquier 2009-06-01 12:56:56 UTC
Created attachment 135729 [details]
Screenshot 4
Comment 15 Philippe Rouquier 2009-06-01 12:57:53 UTC
Created attachment 135730 [details]
Screenshot 5
Comment 16 Michael Monreal 2009-06-01 13:07:07 UTC
Yay for graphical project size indicator. Is the status bar still needed though?

As for the expanders: ugh. This reminds me of the keyboard layout options... which is IMHO the ugliest GUI currently in GNOME. Eliminating dialogs etc is always a fine idea but current Brasero has a clear workflow, something I really miss from the expander UI.

The in-main-window file chooser does not work fine unless you have a large main window, leading to problems for small resolution displays.

Some of the expanded areas look funny (information area) because they only fill a tiny fraction of the area, leaving the rest gray. 

As for "save a click", I'm really not so sure about that: you would have to manually open the options expander every time anyway now to make sure things are set correctly. Also, pressing the burn button now starts recording right away? What about people who accidentally hit it? IMHO a main window like brasero's main window should not try to behave like a dialog, it's confusing.

In the end this looks like a giant regression from what we have right now, sorry.
Comment 17 Philippe Rouquier 2009-06-03 13:27:39 UTC
(In reply to comment #16)
> Yay for graphical project size indicator. Is the status bar still needed
> though?
> 
> As for the expanders: ugh. This reminds me of the keyboard layout options...
> which is IMHO the ugliest GUI currently in GNOME. Eliminating dialogs etc is
> always a fine idea but current Brasero has a clear workflow, something I really
> miss from the expander UI.
> 

I gave it another try and ditched the expander idea. I went for a simpler look that I had put aside at first. This is not fully thought through; in particular:
- I don't know if labels are needed next to media selection/progress bar and media name (perhaps for their mnemonics to move focus around with arrows)
- I don't know what to do with the medium icon as it looks misplaced and will probably be moved to the toolbar as it is only meant for the data project (at the moment it's just hidden for audio and video

In the end, I kept the idea of removing one click by merging burn option dialog and the project. I still think this is the way to go. 

NOTES:
- windows compatibility is not gone. Now, a dialog is displayed whenever a joliet problem is detected.
- most of the messages appearing in the yellow boxes in burn options are still there, in a yellow box as well.
- the project size in the status bar remains as it's gives a new information IMO; in the progress bar/medium selection you have the remaining free space, in the status bar you have the project size which are different information even if there is a link between the 2 of course.

> The in-main-window file chooser does not work fine unless you have a large main
> window, leading to problems for small resolution displays.
> 
I improved this by the way and tweaked it so it can be resized to almost nothing (the only problem here is that brasero won't remember the sizes ATM)

> In the end this looks like a giant regression from what we have right now,
> sorry.
No need to be =). I asked your opinion and you gave it so thanks =).

Screenshot follows.

One last note: if you think that the progress bar is not fancy enough (not as much as Banshee's) don't be disappointed as my goal at the moment is to find where to display such a progress bar and why. The fancy stuff can come later as it comes down to writing a new GtkCellRenderer and that can be done as a second step.

Comment 18 Philippe Rouquier 2009-06-03 13:28:18 UTC
Created attachment 135875 [details]
Second attempt
Comment 19 Fabian Greffrath 2009-06-17 07:23:55 UTC
I am just a random brasero user who stumbled upon this bug report. However, I would like to share my opinion on some of the issues discussed here.

@Luca: Regarding case (b) where no media is inserted yet, why not simply choose the next biggest reasonable media size as 100%? I mean, as long as the user adds files to the project and the total file size is below 700MB, set a blank CD-R (700MB) as 100%. As soon as the user added enough files to break the magical 700MB barrier, a blank DVD-R with 4,3GB will be set as 100% (maybe animized with some blink). If some files are removed and the total file size shrinks back under 700MB, go back to CD-R. This way the program would more or less "suggest" a reasonable media size to the user. Of course, even if only some small files are selected and the bar is still at 700MB on the 100%-side, it will be changed to 100%=4,3GB as soon as the user inserts a DVD-R media. However, "reasonable" media sizes should exclude rather exotic media such as 8cm-CD-R and concentrate on e.g. CD-R (700MB), DVD-R (4,3GB), DVD-R-DL (7,9GB) and maybe BluRay.

@Philippe: Sorry, but I have to wholeheartedly agree with Michael. The expanders will just clutter up the GUI and force you to do even more clicks, because you want to make sure you have checked every expander before clicking the "Burn" button, since there is no more confirmation dialog anymore. The current approach with everythink important visible at first sight and a confirmation dialog before the actual burning process is just perfect IMHO.

Comment 20 Philippe Rouquier 2009-06-27 13:22:22 UTC
This is the final call for comments and testing before closing this bug. Lately I committed my work to close this bug to master. It's completely functional minus the usual small problems that may come up.

The final result is more of less like the latest screenshots I made:
the medium selection bar can now display how much space is used through a GtkCellRendererProgress. That means that when you click the burn button the dialog that follows is different and is now the one you had when you clicked the property button (the one with the speed, burnproof, ...).
As for the fancy part I don't know if it's worth to write a fancy GtkCellRenderer as:
- it will break themes
- it can break keybindings and such things
- I'm not sure it will look good when set into a GtkComboBox.

I'll wait for rhythmbox to write their own widget and see how it looks in the end. If they managed to solve the above issues then I'll convert it into a GtkCellRenderer.

The result may not be what I first thought and what you expected, but though simple is quite satisfactory.
Comment 21 Michael Monreal 2009-06-27 14:08:12 UTC
Created attachment 137458 [details]
Screenshot + Comments

Ok, quick review :)

Screenshot:
- red line: IMHO aligning Name: and Disc: with the status text would look better
- blue line: a bit of padding (like below the Disc: line) would look better
- green: I got this after clearing the date project... this is obviously not right

Other thoughts:
- The Disc: selector shows free space in bytes... megabytes (or even gigabytes for DVDs) would make more sense I think
- What about the simulation etc options? Does "Burn..." now really start burning right away (I did not dare pressing it yet) or does it still open some other dialog for confirmation?
Comment 22 Philippe Rouquier 2009-06-27 18:08:57 UTC
(In reply to comment #21)
> Created an attachment (id=137458) [edit]
> Screenshot + Comments
> 
> Ok, quick review :)
> 
Thanks a lot =)

> Screenshot:
> - red line: IMHO aligning Name: and Disc: with the status text would look
> better
> - blue line: a bit of padding (like below the Disc: line) would look better

yes indeed. Thanks for spotting that, it is fixed in master now

> - green: I got this after clearing the date project... this is obviously not
> right
> 
A bug that was fixed in master (it happened with -R discs only).

> Other thoughts:
> - The Disc: selector shows free space in bytes... megabytes (or even gigabytes
> for DVDs) would make more sense I think
It's not always in bytes and it depends on the size. Brasero uses a GIO function which adapt the unit used according to the amount that should be displayed:
0<X<1024 => bytes
1024<X<1024*1024 => KiB
1024*1024<X<1024*1024*1024 => MiB
and so on.
You saw bytes because your project probably because of the above bug with blank discs.

> - What about the simulation etc options? Does "Burn..." now really start
> burning right away (I did not dare pressing it yet) or does it still open some
> other dialog for confirmation?
> 
yes it opens a new dialog =). As I said in the above comment this leads you to a next dialog (the one you got from pressing "properties" in the former burn option dialog) with a few options like burning speed, burnproof, simulate, eject, ...

Thanks again for your review, they're always helpful.
Comment 23 Michael Monreal 2009-06-27 18:35:29 UTC
Nice work. I can confirm all those things as fixed.

Another small issue: if I click the widget behind "Disc:" after some files have been added to the project (e.g. after the fill bar is shown I get

** (brasero:12688): CRITICAL **: clearlooks_style_draw_box: assertion `width >= -1' failed

and the media's entry is blank (no text visible on that line).

Also I wonder about the dead space behind "Name: [   ]". Maybe just extend the entry to fill the whole line?
Comment 24 Philippe Rouquier 2009-07-13 15:51:17 UTC
Thanks for your review.

The error you're reporting is probably a bug against gtk+ (linked to the use of GtkCellRendererProgress and GtkComboBox). I'll investigate it and file a bug appropriately.

I think that now new bugs should be filed on their own. Thanks everybody for your interest and help.

I'm closing it.