GNOME Bugzilla – Bug 501230
The 'Can not add source files' dialog is too long and his buttons and bottom side are out of the screen
Last modified: 2013-08-31 08:43:58 UTC
Please add scroll button in this dialog. Other information: This situation occurred when I added into project all header files (including one existing already in project) then 'Can not add source files' dialog appears (and one contains to many lines) and dialog window is too long and his buttons are out of the screen.
@seb: Can you check if this is still valid in the new project-manager?
Yes, I haven't changed this dialog so it's still valid.
I have looked at this. I don't know what is the best way to solve this. 1. Do nothing: It appears only when you are not able to add or need to confirm the removal of a big number of files (about 50 here). You can still reach the button pressing Alt key and dragging the dialog. 2. Add a scrollbar in the dialog: It use the standard anjuta_util_dialog_boolean_question function which is using itself GtkMessageDialog. So we need to create our special dialog with a scrollbar. Then it can be a big annoying to scroll all the text, we can perhaps split the text in the main message and details with a scroll only for the detail part. It's difficult to add another argument for a detailed message but we can use a marker. By example if we find "\n\n" in the message string we consider the remaining part as the details. Instead of a scrollbar we can add a expander for the detail part too. Do you have other ideas or know how is it handled in other programs?
I think it's a good idea to display main message like "Do you really want remove 50 files ?" follow by an expander who contain a scroll list composed by all file name
(In reply to comment #4) > I think it's a good idea to display main message like "Do you really want > remove 50 files ?" follow by an expander who contain a scroll list composed by > all file name Well, I think we don't need the expander and the scroll list if the message is small enough. This uses a generic dialog so it can be use in very different situations. I think we can improve it to automatically add an expander and a scrollbar if the message is too long. I imagine that other applications have the same issue, perhaps we could check how they manage this.
(In reply to comment #5) > (In reply to comment #4) > > I think it's a good idea to display main message like "Do you really want > > remove 50 files ?" follow by an expander who contain a scroll list composed by > > all file name > > Well, I think we don't need the expander and the scroll list if the message is > small enough. This uses a generic dialog so it can be use in very different > situations. I think we can improve it to automatically add an expander and a > scrollbar if the message is too long. > > I imagine that other applications have the same issue, perhaps we could check > how they manage this. Why not, and the message passed too the dialog will be formated like "text<mark>text" and the dialog will determine the longer of the second part. But how decide when it must use expander or plain text? Because in our problem it's a good solution too add expander when you have more of 7 file i think, like this you can build a powerfull and "beautifull" dialog. Else we can build plain dialog and if the size of the dialog is bigger than 1/3 of your screen we transform it into expand dialog. Another solution will be too ask the maximum line who can contain plain dialog. I really apreciate to work on this issue, i think it's good approach of anjuta development for me.
(In reply to comment #6) > But how decide when it must use expander or plain text? > Because in our problem it's a good solution too add expander when you have more > of 7 file i think, like this you can build a powerfull and "beautifull" dialog. > > Else we can build plain dialog and if the size of the dialog is bigger than 1/3 > of your screen we transform it into expand dialog. > Another solution will be too ask the maximum line who can contain plain dialog. I think it should be done automatically. This avoid to change the already existing API and is more convenient to use. Then, I don't know if it's better to compare the dialog to your screen size or just count the number of line. But I think just adding an expander if there are more than 7 lines is good enough. > I really apreciate to work on this issue, i think it's good approach of anjuta > development for me. Just write a patch and attach it to this bug report. I will review it and if it's good I will commit it. Ask any questions on the mailing list or in the IRC channel.
Created attachment 250483 [details] [review] It's patch to correct this issue The pach propose to build a new dialog with a message containing a tag "\n\n\n" and the dialog will not contains expander and scroll if details (text after tag) are lower than 7 lines, else the dialog will contains an expander and scroll, but main message are always shown statically
Review of attachment 250483 [details] [review]: Thank you for you patch. It's good. I have only one remark on the code. I think it's better to only search for the '\n' characters in the string to count the number of lines instead of splitting the message in lines and get the length of the result list. Even if it could be easier to write, the program will have to allocate memory to create this list which is some useless work. The main issue is that the layout of the dialog closely follow my own proposal but I'm not convinced by the result. The list of files appears at the end of the dialog, after the note "The source file will be deleted from the file system." while it makes sense to have it just after "Are you sure you want to remove the following source file from the project?". I don't know what is the best solution. Perhaps we can put the scroll area without an expander for the whole text of the dialog and add it only when the height is bigger than the screen height. Or just rewrite the text of the dialog to make it fit better the new layout. What do you think?
Review of attachment 250483 [details] [review]: I'm agree with you for the counting tag and for the layout problem. I tryed to keep the more general situation, for reusability I think it's good to modify the tag type. I was thinking a "xml tag" type must be perfect "<details="NameExpander">Some details</details>" Like that, it will be easier too use, and more powerfulland reusable. Else we can add an option to this tag like "<details="Name" MaxLines="7">" If you think it's good idea i will do it. And i will change the parsing of the message. And thank you for your review.
(In reply to comment #10) > I think it's good to modify the tag type. I was thinking a "xml tag" type must > be perfect "<details="NameExpander">Some details</details>" > Like that, it will be easier too use, and more powerfulland reusable. Else we > can add an option to this tag like "<details="Name" MaxLines="7">" How do you pass such xml tag? In the message string? If yes, that's an interesting idea but I think it's too complex for such dialog. So just adding scrollbar for the dialog message should be enough.
(In reply to comment #11) > (In reply to comment #10) > > I think it's good to modify the tag type. I was thinking a "xml tag" type must > > be perfect "<details="NameExpander">Some details</details>" > > Like that, it will be easier too use, and more powerfulland reusable. Else we > > can add an option to this tag like "<details="Name" MaxLines="7">" > > How do you pass such xml tag? In the message string? If yes, that's an > interesting idea but I think it's too complex for such dialog. So just adding > scrollbar for the dialog message should be enough. The xml tag it's include in the message like "File will be remove from the project!<details="Label Expander">List of file</details>/!\ Warning file will not removed from the filesystem!" It's a little bit heavy but not too much, i think, because when you need a dialog you need user response so you have all ressource free for the operation. I proposed this type of dialog because it's more general. Because with this tag you can add more than one details expander. In this case it's useless but in fact it could be usefull. And the best function of this it's: you can add text after details.... I put the warning message before the expander, because it's a warning so it must be shown at the user, it can't be hiden.
(In reply to comment #12) > The xml tag it's include in the message like "File will be remove from the > project!<details="Label Expander">List of file</details>/!\ Warning file will > not removed from the filesystem!" > It's a little bit heavy but not too much, i think, because when you need a > dialog you need user response so you have all ressource free for the operation. I think it's too heavy for this case. I expect that most of the time, the user will remove file one by one and in some uncommon cases several of them. It's not very convenient to select more than 50 files. Using xml in the message needs a more complete documentation of the function itself. Then what do you do if you have more than one details tag? Moreover, I think it's better to avoid an expander unless it's really needed. In the most common case you want to see the name of the removed files. So I think it will be better to make the dialog as big as possible to fit the screen. Then, we can use an xml tag just to mark text than can be put in scrolled windows. But just split the text in 3: first paragraph always displayed, last paragraph always displayed at the bottom and the remaining which can be put in a scrolled window could be enough. What do you think?
(In reply to comment #13) > Using xml in the message needs a more complete documentation of the function > itself. Then what do you do if you have more than one details tag? I had more scroll window > Moreover, I think it's better to avoid an expander unless it's really needed. > In the most common case you want to see the name of the removed files. So I > think it will be better to make the dialog as big as possible to fit the > screen. I'm not agree with you, if you select the file, you know what you want to remove. So it's useless to show the list of the file. > Then, we can use an xml tag just to mark text than can be put in scrolled > windows. But just split the text in 3: first paragraph always displayed, last > paragraph always displayed at the bottom and the remaining which can be put in > a scrolled window could be enough. What do you think? Like that we lost the generally usage of the dialog window....
(In reply to comment #14) > > Moreover, I think it's better to avoid an expander unless it's really needed. > > In the most common case you want to see the name of the removed files. > I'm not agree with you, if you select the file, you know what you want to > remove. So it's useless to show the list of the file. If you select one or few files indeed you should remember them, but in this case the dialog will fit in the screen anyway. There is an issue only if you select lots of file and in this case, I think it makes sense to list them. > Like that we lost the generally usage of the dialog window.... I agree but I would like to keep something quite simple. I have looked at nautilus which is displaying a warning before deleting files too. The dialog display the name of the file if a single file is selected else it just display the number of files to delete. We can do this too displaying only the number of groups, targets and sources displayed. In this case we don't need to improve the current message dialog. What do you think about this? Your idea to improve the current message dialog is still interesting but I would like to have a practical case where is it used and where it's more useful than in this case.
(In reply to comment #15) > I have looked at nautilus which is displaying a warning before deleting files > too. The dialog display the name of the file if a single file is selected else > it just display the number of files to delete. We can do this too displaying > only the number of groups, targets and sources displayed. In this case we don't > need to improve the current message dialog. What do you think about this? I think it's
(In reply to comment #15) > I have looked at nautilus which is displaying a warning before deleting files > too. The dialog display the name of the file if a single file is selected else > it just display the number of files to delete. We can do this too displaying > only the number of groups, targets and sources displayed. In this case we don't > need to improve the current message dialog. What do you think about this? I think it's a good idea too just show the number of file removed if they have more than 1 file. I will work on it when i can.
I've finished this. I just keep the dialog_with_details_for_more_usage. Also i ask confirmation for removed shortcut.
Created attachment 252693 [details] [review] THe patch I've finished this. I just keep the dialog_with_details_for_more_usage. Also i ask confirmation for removed shortcut.
Review of attachment 252693 [details] [review]: The result of your patch is fine but I have a few requests related to the way it's done. I think it's better to remove the dialog_with_details code in the patch, Of course you should keep and I will commit it when it will be used. Do you really think it's better to ask confirmation for shotcuts? they are quite easy to recreate and I don't think you will try to remove them by mistake. Then, you should remove the old code instead of putting it in comment, if we want to restore it we will look in the file history. Finally, even if it's more efficient, you shouldn't build sentences by concatenating various parts with g_string_append because it makes translation very difficult. The issue is that some languages order words in a very different ways so it's not possible to translate the sentence correctly if you force some order. By the way, there is string freeze period starting the 2 September, so I need your patch before that date to include it in the coming release. Anyway, this is not very important so don't worry if you need more time, in this case it will be included in the next release. Anyway, thanks for your work.
Created attachment 253024 [details] [review] Correct the previous error for translation and for to many function @seb I followed your guidelines, i try to use more plainly text for translation, and i removed the dialog_with_details from the patch. >Do you really think it's better to ask confirmation for shotcuts? Yes i think, because it's more easily for user to ask every time the confirmation or never, but not sometimes.
Review of attachment 253024 [details] [review]: Thank but it's still not right. If nbItem == 1, there is no need to keep the for loop because the messages are not appended anymore (it will just leak memory and keep the last message). Thne the use of g_strconcat is wrong: the argument list must end with NULL and g_strconcat will return a new string that you have to affect to mesg after release the old string.
Created attachment 253076 [details] [review] THe good patch It was a try patch, my fault. I think this one is good. NULL after concat and no enough for, and don't forget the g_free for mesg. Maybe for the 8 patch it will be good ^^ Regards
Review of attachment 253076 [details] [review]: Sorry but I think this one is still not right. I think you miss one part "and g_strconcat will return a new string". g_strconcat doesn't modify the string mesg, it returns a new string so you need to use this one and free mesg. Currently, the last line never appears...
Created attachment 253479 [details] [review] Normally the last Normally this patch correct the issues. You must verify if i didn't make mistake, but i think this time it will be good.
Review of attachment 253479 [details] [review]: Perhaps it would have been easier to use GString instead of C string. Anyway I think this patch is right now so I have committed it. Thank you.