From: Silvan <dmm...@us...> - 2003-02-27 07:17:00
|
I'm trying to do a message box to inform users of a condition where the=20 Lilypond export doesn't have anything to do, and suggest possible remedie= s. The box pops up just fine, but disappears behind everything. I have to g= o dig=20 it out and close it before I can continue. I used 0 for the parent, since I don't know what else to use, and I'd see= n=20 some examples of that. Not only does the box remain hidden, I can't even get it to come up with = the=20 thingie on the task bar. It always flashes right to the back until I mov= e=20 the Rosegarden window out of the way. I assume that this is because I used 0 for the parent instead of a pointe= r to=20 some graphical flumwhatzit that would put this in a useful visual context= , so=20 what _should_ I use? A pointer to the main window or something maybe... My grasp on all of th= is is=20 still rather tenuous. While I'm writing, here's the text for Chris/anyone to object to here and= now,=20 so I can fix it up before I go any further with this... KMessageBox::sorry(0, i18n( "All tracks were muted, so there were no notes to export.\n\n" "For better results, either un-mute some tracks or toggle off t= he " "\"Do not export muted tracks\" option on the Lilypond tab of t= he " "Notation configuration page, then try again.")); I'll just comment this out for the time being, but I think it's a good th= ing=20 to warn people about. Feel free to pick at the wording and such if it's = not=20 consistent with Rosegarden's overall design philosophy or whatever. I'm = just=20 trying to be nice, so people don't end up with a useless .ly file without= =20 some idea why it is thus. This feature seems to be working now, BTW. I'll commit this soon to get=20 people to take a look and see if I'm missing anything, but so far so good= =2E =20 I'm going to go close out my feature request. This particular implementa= tion=20 isn't quite what I envisioned, but I can't see assembling and presenting = a=20 new dialog box with a list of staffs and checkboxes when it's so flat eas= y to=20 just use the mute status as a basis for excluding certain tracks. Didn't= =20 Rich say laziness was a *good* thing? :) --=20 Michael McIntyre USDA zone 6b in SW VA, USA Silvan <dmm...@us...> Linux Druid ----------[ registered Linux user #243621 ]--------- http://www.geocities.com/Paris/Rue/5407/index.html |
From: Chris C. <ca...@al...> - 2003-02-27 10:01:07
|
Silvan wrote: > The box pops up just fine, but disappears behind everything. [...] > I used 0 for the parent, since I don't know what else to use, and I'd seen > some examples of that. I'm pretty sure 0 should work. There is a progress dialog for Lilypond export, isn't there? I have recently noticed a similar thing myself when getting an error on .rg file load at startup. What happens there (assuming the error happens before the progress dialog's popup timer has timed out) is that the error appears in front of the main window, but as soon as the progress dialog appears, the error dialog gets pushed right to the back, behind the Rosegarden window, and as you say, it's entirely unrecoverable. Try starting up Rosegarden with a bogus file on the command line and see what you get. > While I'm writing, here's the text for Chris/anyone to object to Looks fine to me. Chris |
From: Silvan <dmm...@us...> - 2003-02-27 15:20:44
|
On Thursday 27 February 2003 04:58 am, Chris Cannam wrote: > I'm pretty sure 0 should work. OK then, it must be something else... > There is a progress dialog for Lilypond export, isn't there? I have > recently noticed a similar thing myself when getting an error on .rg Yes. I've noticed this now... I have to press cancel on the progress di= alog=20 before I can even close out my message box, even if if I move things out = of=20 the way to the point where I can get to it. I hadn't ever even seen the progress box before either, actually. It, to= o,=20 was hiding behind the main window, or else flashing by so fast I never sa= w=20 it. I've set the progress emitter thingie to just start off at 100% to get th= at=20 out of the way quickly. I'll see if that makes my message box behave mor= e=20 politely. Maybe then I can emit a 100% right before popping up the messa= ge=20 box? > Try starting up Rosegarden with a bogus file on the command line and > see what you get. Just said "The specified file does not exist" right on top and everything= =2E No=20 problems there. > > While I'm writing, here's the text for Chris/anyone to object to > > Looks fine to me. OK, I'll leave it alone then, but I won't actually activate the code unti= l I=20 can figure out a way to make it behave less obnoxiously. --=20 Michael McIntyre USDA zone 6b in SW VA, USA Silvan <dmm...@us...> Linux Druid ----------[ registered Linux user #243621 ]--------- http://www.geocities.com/Paris/Rue/5407/index.html |
From: Guillaume L. <gla...@te...> - 2003-02-27 10:59:11
|
On Thursday 27 February 2003 08:16, Silvan wrote: > Not only does the box remain hidden, I can't even get it to come up with > the thingie on the task bar. It always flashes right to the back until I > move the Rosegarden window out of the way. Strange. I suppose this is the only message box for which you see this behavior ? > I assume that this is because I used 0 for the parent instead of a pointer > to some graphical flumwhatzit that would put this in a useful visual > context, so what _should_ I use? No, as Chris said 0 is correct in this specific case. > This feature seems to be working now, BTW. I'll commit this soon to get > people to take a look and see if I'm missing anything, but so far so good. Tell me when it's in so I can take a look. > I'm going to go close out my feature request. This particular > implementation isn't quite what I envisioned, but I can't see assembling > and presenting a new dialog box with a list of staffs and checkboxes when > it's so flat easy to just use the mute status as a basis for excluding > certain tracks. Didn't Rich say laziness was a *good* thing? :) It is, but in that case I wonder if that kind of effect (muting a track disables its export) wouldn't be a bit unexpected. -- Guillaume http://www.telegraph-road.org |
From: Chris C. <ca...@al...> - 2003-02-27 14:06:27
|
Guillaume Laurent wrote: > Strange. I suppose this is the only message box for which you see > this behavior ? Have you tried the case I described (file error on loading at startup, pushed to the back by a progress dialog)? I actually can't test it again from here because funnily enough it doesn't seem to happen with my own window manager, but it was definitely happening under KDE yesterday at home. Chris |
From: Guillaume L. <gla...@te...> - 2003-02-27 11:21:16
|
On Thursday 27 February 2003 12:14, Chris Cannam wrote: > Guillaume Laurent wrote: > > Strange. I suppose this is the only message box for which you see > > this behavior ? > > Have you tried the case I described (file error on loading at > startup, pushed to the back by a progress dialog)? No, but that could be the reason indeed, the progress dialog being modal (I think). If so, you need to call CurrentProgressDialog::freeze() before popping up the msg box. Then again, the msg box should be popped up *before* any export work is done. I'd almost say that the lilypond export menu item should be disabled when all tracks are muted, but that would be really confusing. Which is perhaps another hint that this feature is inherently confusing... Mmmh. -- Guillaume http://www.telegraph-road.org |
From: Chris C. <ca...@al...> - 2003-02-27 11:33:02
|
Guillaume Laurent wrote: > Then again, the msg box should be popped up *before* any export work is done. But not necessarily before the dialog object is created? Chris |
From: Guillaume L. <gla...@te...> - 2003-02-27 12:57:35
|
On Thursday 27 February 2003 12:29, Chris Cannam wrote: > Guillaume Laurent wrote: > > Then again, the msg box should be popped up *before* any export work is > > done. > > But not necessarily before the dialog object is created? No, the progress dialog should not be created if there's nothing to export because all tracks are muted. Not sure what you have in mind here. -- Guillaume http://www.telegraph-road.org |
From: Chris C. <ca...@al...> - 2003-02-27 13:10:57
|
Guillaume Laurent wrote: > On Thursday 27 February 2003 12:29, Chris Cannam wrote: > >>Guillaume Laurent wrote: >> >>>the msg box should be popped up *before* any export work is >>>done. >> >>But not necessarily before the dialog object is created? > > No, the progress dialog should not be created if there's nothing to export > because all tracks are muted. Not sure what you have in mind here. Well, you seem to be talking about what _should_ happen. I haven't seen Michael's code, but at the moment creating the progress dialog is the very first thing that happens in the Lilypond export method, certainly before the LilypondExporter is constructed (apart from anything else, its constructor requires a progress reporter to attach to). So it's not unreasonable to suppose that at the moment the dialog is created before the message box is popped up. We're probably just talking at cross-purposes -- me descriptively, you prescriptively. An ambiguity in the use of the word "should". I think it's reasonable enough to base the selection of tracks to export on their muted status, btw. At least for the moment. Chris |
From: Guillaume L. <gla...@te...> - 2003-02-27 15:10:18
|
On Thursday 27 February 2003 14:06, Chris Cannam wrote: > > We're probably just talking at cross-purposes -- me descriptively, > you prescriptively. An ambiguity in the use of the word "should". OK, so : - Ideally, if there's nothing to export then a message box telling why should be popped up right away, no progress dialog should even be created, etc... - currently, if the progress is created first, then CurrentProgressDialog::freeze() should be called prior to popping the message box, then CurrentProgressDialog::thaw() once the msg box returns. There are other examples of this throughout the code, grep for "freeze()" or "thaw()". > I think it's reasonable enough to base the selection of tracks to > export on their muted status, btw. At least for the moment. Couldn't we at least have a simple message box asking "don't export muted tracks ? Yes / No" so as to make the feature clear ? -- Guillaume http://www.telegraph-road.org |
From: Chris C. <ca...@al...> - 2003-02-27 15:30:05
|
Guillaume Laurent wrote: > Couldn't we at least have a simple message box asking "don't export muted > tracks ? Yes / No" so as to make the feature clear ? Well, it is a configurable option -- although the default appears to be on (i.e. don't export). Chris |
From: Chris C. <ca...@al...> - 2003-02-27 16:14:30
|
Chris Cannam wrote: > Well, you seem to be talking about what _should_ happen. [...] > We're probably just talking at cross-purposes -- me descriptively, > you prescriptively. An ambiguity in the use of the word "should". *sigh* or indeed the distinction between should and _should_. let's just avoid English. Chris |
From: Chris C. <ca...@al...> - 2003-03-02 10:52:54
|
On Thursday 27 February 2003 11:21, Guillaume Laurent wrote: > On Thursday 27 February 2003 12:14, Chris Cannam wrote: > > Have you tried the case I described (file error on loading at > > startup, pushed to the back by a progress dialog)? > > No, but that could be the reason indeed, the progress dialog being > modal (I think). If so, you need to call > CurrentProgressDialog::freeze() before popping up the msg box. Yeah, looks like several of the messages in rosegardenguidoc lacked=20 that freeze() call (in fact there were no freeze() calls anywhere in=20 rosegardenguidoc.cpp). So the error that occurred when trying to=20 load a corrupted file (as opposed to loading a nonexistent file --=20 that error was outside any progress-reporting region) got pushed to=20 the back by the progress dialog. I've added a call to freeze(), but there's still a problem -- the=20 progress dialog gets out of the way nicely, but the splash screen=20 remains in front of the error dialog. This doesn't happen with the=20 nonexistent file error (rosegardenguidoc.cpp:376), only with the=20 corrupted file error (rosegardenguidoc.cpp:402). Why? Chris |
From: Silvan <dmm...@us...> - 2003-02-27 16:31:20
|
On Thursday 27 February 2003 05:59 am, Guillaume Laurent wrote: > Tell me when it's in so I can take a look. I'll go commit it now. I'm not done working on stuff, but nothing major = is=20 broken at the moment AFAIK. I've had another look after doing the forced 100% thing I just spoke of. What it looks like to me is: progress box remains hidden while counting up... If it gets stuck at 66%= ,=20 say, then I have to go dig it out to cancel it. If I hack it to jump to=20 100%, then it pops right up, making it easier to get it out of the way. When it's on top, and when it's cancelled, then my message box jumps to t= he=20 front as expected. So the message box is holding up the progress reporter, by causing=20 LilypondExporter not to destruct itself in a timely fashion, forcing a wa= it=20 for the manual cancel or timeout, and the progress reporter itself doesn'= t=20 seem to be behaving very well if I never see it until the end. I never=20 noticed the thing until I put in that message box, and wondered if Rich's= =20 code actually did anything. I'll go ahead and comment my message box back out because this is very=20 annoying, but you'll see where it is. I can see how this problem could affect any similar thing for which there= 's a=20 progress reporter, and Chris is probably seeing another manifestation of = the=20 same phenomenon. > It is, but in that case I wonder if that kind of effect (muting a track > disables its export) wouldn't be a bit unexpected. That's why it's a toggle... Since you think this might be confusing, I=20 changed it to default to off. It's definitely useful when you want it to= =20 happen that way, and it's convenient. The more I think about it, the more the way I did it seems like a good id= ea. =20 It's a feature for free, and it won't bother anyone who doesn't want to u= se=20 it. Other ways to provide this functionality would involve considerably = more=20 infrastructure, and more effort on the part of the user. I'd much rather= =20 toggle off the mute buttons than have to diddle some dialog every time I=20 export. It feels logical to me... Don't hear it, don't see it on the=20 page... --=20 Michael McIntyre USDA zone 6b in SW VA, USA Silvan <dmm...@us...> Linux Druid ----------[ registered Linux user #243621 ]--------- http://www.geocities.com/Paris/Rue/5407/index.html |
From: Guillaume L. <gla...@te...> - 2003-02-27 17:16:44
|
On Thursday 27 February 2003 17:30, Silvan wrote: > > I've had another look after doing the forced 100% thing I just spoke of. You should not have to force the value. If you have to then you have a problem elsewhere. > What it looks like to me is: > > progress box remains hidden while counting up... If it gets stuck at 66%, > say, then I have to go dig it out to cancel it. If I hack it to jump to > 100%, then it pops right up, making it easier to get it out of the way. > > When it's on top, and when it's cancelled, then my message box jumps to the > front as expected. When is you message box created ? Right at the beginning, or after the export has started ? What is apparently happenning is a deadlock between the progress dialog and the message box. The progress isn't updated anymore because your code is waiting on the result of the message box, but the message box can't appear because the progress dialog has grabbed focus. So yes, that's what CurrentProgressDialog::freeze() is for. However, as I said, in your particular case this is the wrong solution because the message box should be popped up *before* any work is done on the export. You should not start writing stuff and all of a sudden warn the user about a condition which he should be told about first hand. > The more I think about it, the more the way I did it seems like a good > idea. It's a feature for free, and it won't bother anyone who doesn't want > to use it. Other ways to provide this functionality would involve > considerably more infrastructure, and more effort on the part of the user. > I'd much rather toggle off the mute buttons than have to diddle some dialog > every time I export. It feels logical to me... Don't hear it, don't see > it on the page... Yes, but generally you mute/unmute tracks much more often than you export stuff. I agree that using the muted status of the tracks to filter out unwanted tracks on export is convenient, but I'm not sure it's intuitive. However, if there's a toggle then the feature is not "hidden", so I'm happy with it as it is. -- Guillaume http://www.telegraph-road.org |
From: Silvan <dmm...@us...> - 2003-02-27 21:49:22
|
On Thursday 27 February 2003 12:16 pm, Guillaume Laurent wrote: > You should not have to force the value. If you have to then you have a > problem elsewhere. I was just experimenting, trying to get the progess thingie to hurry up a= nd=20 relinquish its focus. It didn't work, of course, and I wouldn't have lef= t it=20 in if it had. I was just trying to see exactly what was happening. > When is you message box created ? Right at the beginning, or after the > export has started ? Toward the end of the loop, when it's clear that no segments have been=20 exported. > the export. You should not start writing stuff and all of a sudden warn= the > user about a condition which he should be told about first hand. OK, I have to concede that you're right. While people might actually wan= t to=20 export an empty file (all the stuff is in there; just no notes, and the f= ile=20 actually renders) to use as a template or something, and should be given = that=20 choice, they should be given a chance to abort before anything is written= if=20 that's not what they really meant to do. I'm trying to sort out far more critical problems at the moment. Problem= s=20 that cause the files not to render at all, or to render badly. I think i= n=20 the spectrum of bad things, an empty skeleton file that renders as a most= ly=20 blank page is less of a problem than a file that crashes Lilypond and ask= s=20 the user to submit a bug report, so I'm prioritizing... I'll just leave out the message box entirely for the moment. There's alr= eady=20 a comment in the .ly file, so people will figure it out if anyone happens= to=20 build CVS, discover and turn on this option, then export a composition wh= ere=20 all the tracks are muted before I get time to deal with this properly in = the=20 next several days. > However, if there's a toggle then the feature is not "hidden", so I'm h= appy > with it as it is. Yeah, FWIW, the toggle was in there before the feature even worked. I re= alize=20 this is something that needs to be controllable. As far as intuitive... I think the most intuitive thing would be an "exp= ort=20 the stuff I'm looking at in this notation view right here" option. Some=20 other day, perhaps. --=20 Michael McIntyre USDA zone 6b in SW VA, USA Silvan <dmm...@us...> Linux Druid ----------[ registered Linux user #243621 ]--------- http://www.geocities.com/Paris/Rue/5407/index.html |
From: Guillaume L. <gla...@te...> - 2003-02-27 22:33:34
|
On Thursday 27 February 2003 22:49, Silvan wrote: > I'll just leave out the message box entirely for the moment. There's > already a comment in the .ly file, so people will figure it out if anyone > happens to build CVS, discover and turn on this option, then export a > composition where all the tracks are muted before I get time to deal with > this properly in the next several days. OK, that's not a really crucial problem anyway. > As far as intuitive... I think the most intuitive thing would be an > "export the stuff I'm looking at in this notation view right here" option. Agreed. -- Guillaume. http://www.telegraph-road.org |