GNOME Bugzilla – Bug 594912
The target advanced options window should remember its size.
Last modified: 2012-04-05 19:34:42 UTC
Created attachment 143002 [details] target advanced options window Hi, It would be useful if the target advanced options window (cf attached file) remains its size. I mean, if I resize it, close it and open it again, it should have the same size that when I closed it. Eloi
Which class is responsible for this? I only found AnjutaPreferencesDialog and this class build the normal preferences window.
This is somewhere in the project-manager if the dialog still exists.
The advanced option dialog doesn't exist but it has been replaced by another one allowing to set properties for all nodes so targets, sources and groups too. It is created by the function pm_project_create_properties_dialog in plugins/project-manager/dialogs.c The content of this dialog can change quite a lots depending on the node chosen (group, target, source...) and on the node itself as all properties having their default value are hidden by default. I think it could be difficult to keep a size useful for all cases. Perhaps we can keep at least a size for each kind of nodes.
Created attachment 210377 [details] [review] sets the height of the window
It's not perfect, but I didn't find a way to get the height of the particular nodes.
Review of attachment 210377 [details] [review]: Apart from the commit title this look OK to me. Getting the size of a widget that hasn't been drawn yet is tricky and 30 seems to be a reasonable default for an entry. But I leave that one the Sebastien.
Review of attachment 210377 [details] [review]: I think it would be better to use gtk_widget_get_preferred_size and compute a size big enough to avoid both scroll bars. The default size of the dialog doesn't reserve space for the properties table because it is inside a scrolled window. The glade file contains some predefined size for the properties table which could be removed too. The request was to save and restore the dialog size but as I have said it's difficult to do. So indeed resizing it automatically depending on its content is I think better.
Created attachment 210508 [details] [review] add resizing properties dialog The properties dialog window should now update the geometry by changing the dialog content or creating a new dialog window. Now my only problem is: How can I detect when "More options" is expanding? Because when "More options" is expanding, the dialog window doesn't update the geometry at the moment.
Review of attachment 210508 [details] [review]: Thanks for your improved patch but instead of using only the already existing widget, I think it would be better to directly get the size of the dialog and add the size of the scrolled window content. This will allow to take into account the margin of the dialog and you will not need any hard coded numbers. Else for your question, I think you can try to use the "activate" signal of the GtkExpander object else I think you can connect to the changed signal of the expanded property to know when the "more options" is expanded. But you can have a lot of additional properties, so I think you should not resize the dialog to display all of them as it will be probably bigger than the screen. Anyway I'm agree that increasing its height will be better.
Created attachment 210673 [details] [review] add resizing properties dialog The window size is at most 3 / 4 of the screen width and height now. I remove the hard coded code and use the dialog size as minimum and sum the other sizes to this. The only thing what me disturb is, that height of expanded windows is too "height". They can be a bit smaller without the drawing the scrollbar. Additionally to that the height is wrong, when you open the property window change the target many times inside the opened window.
Review of attachment 210673 [details] [review]: Thanks for your patch. I think it's good enough now but I have two remarks. * I think getting the size of the help button is useless now. * Why do you check the state of the expander and count its height as 0 if it is not expanded? Here, the properties dialog are a bit too small when you get the property of a target. While it's a bit too big if I'm always considering the height of the expander whatever is its state but I think it's nicer like this. We could perhaps avoid the extra size by getting the size of more widgets. By example I imagine that the content of the view port widget is not zero even if it is inside a scrolled window, and I think the scrolled window include the scroll bar which are not present when the dialog is big enough. So Adding the expander and the table size to the dialog size gives something bigger. You can try to be more precise by checking the size of the other widgets like the view port widget or the scrolled widget but I don't think it's necessary. Updating the size of the dialog, when the expander widget is expanded or collapsed, is a nice improvement.
Created attachment 211095 [details] [review] add resizing properties dialog * I forgot to delete the variable with the size of the help button. So you're right, it's useless now. * After a new retry of getting the right height, I've got it. The window should now have the right size of height. I set the minimum of "GtkScrolledWindow" to 0. In my mind, it's not really nice, but it works.
Created attachment 211114 [details] [review] add resizing properties dialog This version should be better than the previous one. I subtract the real minimum height of the scrollbar from the dialog minimum height now.
Review of attachment 211114 [details] [review]: I have still a vertical scrollbar by example on libanjuta-interfaces.la properties in Anjuta. I think it's because the height of the viewport is not taken into account. Perhaps it depends on your current theme. I think that instead of computing the height using main_size.height + expand_size.height, it would be better to get directly the height of the viewport so you will be sure that you take everything into account. Here it fixes the issue. Then, instead of getting the parent of the main_table widget, it would be better to get a pointer on the scrolled window and on the viewport widget in the pm_project_create_properties_dialog function and keep them in PropertiesTable object. This will make the code easier. Finally there is one last issue, that you can see it on pixmaps/48x48 group properties. It could be that the width of the widget main_table is bigger than both the head and the expand width. In this case a horizontal scrollbar is draw which invalidate the computation for the the height. I think it would be better to use width = viewport.width + border_width
Created attachment 211271 [details] [review] add resizing properties dialog You're right. The code is easier by putting the scrolled window and viewport widget to PropertiesTable object. I had add the width of the vertical scrollbar to the width of the window. If the vertical scrollbar is showing, the window will width enough to hide the horizontal scrollbar.
Review of attachment 211271 [details] [review]: This patch is good, I have just some questions on one line: gint width = (head.width>viewport.width)?head.width:viewport.width + vscrollbar_minimum.width + border_width; First, if head.width > viewport.width why do you use head.width? In this case, the width of the dialog is defined by the width of the head part which has no scroll bar so there is no calculation to do, the best width is just dialog.width. I think it's working if you put a smaller value like head.width as the dialog will automatically be resize but it looks strange no? Then if head.width < viewport.width, why do you add vscrollbar_minimum_width? You already have compute the height of the dialog to avoid this scrollbar, so you don't need to take it into account. Or do you plan this additional space, in case the dialog is taller than 3/4 of the screen? In this case perhaps it can be done only here. Moreover strictly speaking we should probably compare head.width with (viewport.width + vscrollbar_minimum.width) but I'm not sure it worths the additional code. Finally, I'm using space around operators and you have used them around +. I think it's better to use them around >, ? and : too but it's not very important. Anyway, I don't need a new patch, just answering these questions is enough. It's possible that I have missed something and that the patch is better without any change else I can do these small changes myself.
I forget, why I calculate the width and don't use dialog.width. Maybe I use it at the begin of writing the patch and dialog.width didn't work at this moment. Finally I learn bit by bit about GTK+, so this line makes no longer sense now. I wrote the part with the vscrollbar_minimum_width so, because if the user shrink the height of the dialog, there will be sometimes showing a horizontal scrollbar, because the vertical scrollbar doesn't fit. But you're right once more, this can be done, if the dialog is taller than 3/4 of the screen. The last point is a bad habit of mine. Of cause the code looks better with space around the operators.
Thanks for your answers and for your work. I have committed your last patch just adding whitespace and using dialog.width. It doesn't exactly implement the request but I think it's a good alternative so I close the bug too.