geeqie
geeqie copied to clipboard
BestImageViewer
Problem with window in the current build
ISSUE TYPE
- Bug Report
GEEQIE VERSION
Geeqie 1.5.1+git20201014-a54864bf
Compiled with all options/libraries using the geeqie-install-debian.sh script
OS / DISTRIBUTION
SUMMARY
In version 1.5.1, the menubar and toolbar run across the screen above the left sidebar where the file and thumbnails are displayed. In the current build, these menus are restricted to the sidebar, thus, if you narrow the sidebar down narrower than the menus, the file list and thumbnails get shoved off the screen to the left where they cannot be seen.
I suggest restoring these toolbars back to their original position.
STEPS TO REPRODUCE
Drag vertical divider between pane (see image) to left and the thumbnails and file navigation will move out of frame.
I think that is a difference in the way GTK2 and GTK3 behave. If you can compile from sources, you have the option of using the GTK2 style, although eventually GTK2 will disappear. The latest version has the option to extend the menus across the top of the window - which is ok for me as I use a lot of icons, but created displeasure in a few other users - hence the option.
It was discussed. Making it go through the whole window also is a bad solution. It wastes space in picture pane. I think it should be made collapsible in some way. Right now left pane uses too much screen space.
It was discussed. Making it go through the whole window also is a bad solution. It wastes space in picture pane. I think it should be made collapsible in some way.
The option is on Edit/Preferences/General - it needs a restart.
(I use the mouse most of the time, and have many icons on the toolbar - that plus two screens makes it a good way for me. But there now is the option to switch between the two layouts.)
Thanks for the info. Using the option resolved the problem. I'd rather give up the vertical space in the image window than suffer the problem, but I agree with tomaszg7 that when constrained to the left pane, it requires too much horizontal space. I typically run with two columns of icons shown and this is too narrow for the menus. Maybe there is another solution, but forcing the file and thumbnail lists left isn't it! Maybe having the toolbars split to two+ rows to fit the narrower space?
Also, I just noticed that I can start multiple versions of 1.5.1, but can only start a single version of the development build. Is that another artifact of GTK3 or am I doing something wrong? (I've had all sorts of windows problems since Xubuntu went to GTK3. I don't think that kit was ready for prime time when it was introduced and I still have problems with Xfce supporting two independent monitors because of it.)
It is possible to include a horizontal scroll-bar under the menus box. The two attached images show an example. But the vertical space for the scroll-bar is always allocated, and you still have to scroll to get to a menu item. (The toolbar widget has a built-in capability to show an overflow menu).
The gtk3-demo program has a demo. item for menus, and shows that menus can be flipped to a vertical orientation. So the menus could be orientated vertically on the left side of the folders box - but that takes up horizontal space that might be used by people who have the folder set to tree view. Do any programs use vertical menu layouts?
but can only start a single version of the development build.
There should be no difference between the two versions
I've had all sorts of windows problems since Xubuntu went to GTK3.
GTK4 is not too far away.
Wouldn't it be possible to make menu behave in the same way as toolbar? I.e. show down arrow to see elements which don't fit?
Wouldn't it be possible to make menu behave in the same way as toolbar?
The toolbar widget has the function gtk_toolbar_set_show_arrow (), which the menu widget does not. It could be implemented of course - showing a pop-up menu when the widget size goes below a minimum. Do you know of any programs that can handle when the user makes the menu bar too small? It would be good if someone else has already solved this problem.
But the vertical space for the scroll-bar is always allocated
Actually this is not so - by using the size-allocate signal it is possible to hide/show the scroll-bar depending on the displayed width of the widget.
I discovered the problem of not being able to start multiple versions of the development build. I start the program from a script I've written and I was accidentally including the -r flag which I got from an example on the man page while working on another problem. Once I removed this, multiple copies started as expected.
Also, (from your comments on the developer forum) setting the three environment variables XDG_DATA_HOME, XDG_CONFIG_HOME and XDG_CACHE_HOME did resolve the conflict between running multiple versions of the program. Thanks!
Now that I've got the development build running in a useful way, I'll just mention that I do see flashing of the image in the image pane every time the mouse travels over a window frame edge. This includes when moving between the image frame to the thumbnail frame, although it is more pronounced when exiting the application frame edges. This does not occur with the official 1.5.1 release.
I second tomaszg7's idea about menu overflow. That seems like a much better idea than the things I was suggesting.
Finally, regarding vertical menus: I'm not a fan of them, but one program that uses them is LibreOffice which has a vertical toolbar that slides in/out from the screen edge. This is dockable so it can probably be detached and float -- or even turned into a horizontal bar. I haven't played around with it.
Another program with a vertical menubar with text is RawTherapee.
I thought I saw some programs to use the arrow in menubar but can't find any right now. I don't know if they changed behaviour (or GTK did that). I did find some programs using QT to be able to do it - e.g. Musicbrainz Picard.
Alternatively, you could do what browsers (e.g. Firefox) are doing and use a "hamburger" style icon to hold the whole menu inside.
Now that I've got the development build running in a useful way, I'll just mention that I do see flashing of the image in the image pane every time the mouse travels over a window frame edge
This is a GTK2/GTK3 problem.
GTK2 -> no problem GTK3 with no gpu accel -> problem GTK3 with gpu accel -> no problem (GTK4 -> probably any number of problems)
Go to Edit/Preferences/Image and select gpu accel. - restart required.
use a "hamburger" style icon to hold the whole menu inside.
If you mean put a "hamburger" item - displaying the top-level menu items - as the first entry on the menu bar, yes, that sounds like a good solution. But because of the different ways that GTK2 and GTK2 operate when widget width is decreased, the burger will need to be the first item on the menu in GTK2, and in GTK3 the burger will need to be the last item. In terms of implementation, that might be easiest.
Hmmm, there is no acceleration option on my preferences.
I didn't find it anywhere else in the preferences. I'm using a Nvidia K4000 GPU with dual screens.
If you are compiling from sources, please try this sequence:
sudo make maintainer-clean; ./autogen.sh; make -j; src/geeqie
I followed these instructions and it rebuilt just fine. There was a new acceleration entry (along with some other minor changes as seen here) and when I selected it and restarted, the flashing disappeared. Thank you!
BTW, a very minor item, but I'm a command line guy and rarely have a file browser open. I have to open one just to drag/drop files here. If there is an option to turn on a toolbar item to browse and load a file as part of this forum software, that would be useful -- but not necessary if it's any sort of problem.
I forgot to ask: Now that the above procedure has been performed, if I want to update later can I now just rerun the geeqie-install-debian.sh script, or do I need to always repeat the above sequence on a full refreshed download?
I got a million of 'em!
Now that I'm trying out the development build, I noticed that if I start up multiple geeqie windows, then I can close the 2nd through nth window independently (using the [x] window icon), but if I close the 1st instance, then it takes down all of the other geeqie windows with it. Ctrl-Shift-W in the 1st window does the same thing.
On the other hand Ctrl-Q in any of the windows kills everything -- apparently with prejudice because when I restart geeqie, all the windows that were up are redisplayed. This does not happen when you kill everything using [x] or Ctrl-Shift-W in the 1st window; then only the first window is redisplayed.
I'm launching the viewer with this command:
XDG_DATA_HOME=/u/jeff/.config_alt XDG_CONFIG_HOME=/u/jeff/.config_alt XDG_CACHE_HOME=/u/jeff/.config_alt /usr/lbin/geeqie . >/dev/null 2>&1 &
if I want to update later can I now just rerun the geeqie-install-debian.sh script, or do I need to always repeat the above sequence on a full refreshed download?
The "maintainer-clean" etc. instructions are part of the script, so it should be necessary only to run the script. I don't understand what happened, but if it consistently occurs then that is of interest. Although the script is called "install", if you have already used the script to install Geeqie, running the script again will download the latest commits and replace the existing version with the updated version.
Now that I'm trying out the development build, I noticed that if I start up multiple geeqie windows, then I can close the 2nd through nth window independently (using the [x] window icon), but if I close the 1st instance, then it takes down all of the other geeqie windows with it. Ctrl-Shift-W in the 1st window does the same thing.
The window implementation has caused some grief in the past... The current implementation requires that a "main" window always exists - that's just the way it is. If you have multiple windows open, and want that same layout the next time, use Quit. On next start of Geeqie, everything will be re-opened as before. If the multiple windows were of no significance, either close the main window, or select one of the subsidiary window and press-and-hold control-w (although I see you use control-shift-w). On next start only the main window will be opened.
There is an option in Edit/Preferences/Windows to show the window IDs. Also the case of the word "Geeqie" in the title bar indicates if it is the main window.
The menu item Windows allows you to save windows as named layouts, and recall them at any time - e.g. a layout that is all icons, or with sidebars.
The toolbar widget has the function gtk_toolbar_set_show_arrow (), which the menu widget does not.
I was thinking that maybe it would make sense to have a possibility to make menu stretch to the whole width of the window, but keep toolbar short. Even better would be to have a possibility to dock this toolbar in many places - under menu, inside thumbnails pane, vertically at window border and so on.
I was thinking that maybe it would make sense to have a possibility to make menu stretch to the whole width of the window, but keep toolbar short. Even better would be to have a possibility to dock this toolbar in many places - under menu, inside thumbnails pane, vertically at window border and so on.
Or possibly put the toolbar to the right of the menubar and have only a single bar running across the top of the application window. I think that would be my preference for both layout and functionality.
The current implementation requires that a "main" window always exists - that's just the way it is.
That's very unfortunate. I assume this is another GTK3 limitation. It's a head-scratched as to what the developers of this toolkit are up to. This trend of eliminating -display support which keeps applications (LibreOffice, I'm talking about you) from opening multiple independent sessions on different displays (or even on the same display!), and removing the -geometry option to allow precise sizing and positioning, just seems insane to me. It's all part of an industry trend that we see with Google, Facebook, etc. which eliminates the option for users to control the software, with the developers making the decisions for them. Anyway, thanks again for the clear explanation.
Speaking of window size and positioning, I don't like having subsequent windows open directly over the main window (sometimes it not clear that the new window even opened if it's in the same directory as the main), so I unchecked Use saved window positions also for new windows so that it becomes clear where the new window is. The problem is that the new windows open as a tiny rectangle and I always have to resize it to be useful. I tried launching Geeqie with the --geometry=1862x2039 option specifying size but no position. This open the main window with the specified size while using the last saved position. (It will also honor the positioning for the main window if specified.) However, for subsequent launches the --geometry option is being ignored completely and the windows open as the little rectangles which are 1125x500 in size. (I assume this is some sort of built-in default value.)
So the question is whether it is possible to somehow control the default size of all windows being opened, independent of the window positioning?
P.S.: I just discovered something else interesting. I had three Geeqie windows opened: main at my specified geometry and two subsequent small windows as discussed above. I used Ctrl-Q to terminate everything and then restarted Geeqie. All three windows were redisplayed roughly where they were before, but all three used the saved width and height of the main window! So the positions of each seemed to be remembered, but not the sizes. I'm passing this along FYI.
the windows open as the little rectangles which are 1125x500 in size
Maybe the window manager has an influence - the default size is 700x500. If 1125x500 seems small, it is probably because you are using a 4k or 8k monitor. When GqView first appeared, monitors were about 800x600, so 700x500 seemed reasonable. It is possible to set the defaults proportional to the resolution of the screen being used. A simple scale-up would not be good - 90% of a 800x600 screen is ok, but 90% of a 4k screen would be excessive.
were redisplayed roughly where they were before, but all three used the saved width and height of the main window
I can't replicate this effect. If it is reproducible please take a look at $HOME/.config/geeqie/geeqierc.xml.
The window placements and dimensions are in the layout sections at the end of the file. Please check if the dimensions are being saved correctly, or if they are saved correctly but ignored on restart.
Alternatively, you could do what browsers (e.g. Firefox) are doing and use a "hamburger" style icon to hold the whole menu inside.
The attached .diff is an implementation of this. One advantage is that it is minimal effort. Another is that the entire menu can be torn-off - but then the GTK developers have decided that tear-off menus are deprecated. 820-1.diff.gz
Tried that patch and noticed a few problems:
- I don't see the icon for the new menu. I see only unknown unicode glyph.
- Adding it to the menu solves nothing - it should be present instead of normal menu. This way it only increases the amount of space used by menu. It should probably be controlled by a preferences toggle. Without menu the icon could be placed as a first (or last?) item on the toolbar.
- What about accelerators? Could they be made to work if no normal menu is visible?
Additionally, the possibility of shrinking the left pane shows another minor issue - in thumbnail list view data is very long. It would benefit be better if it could wrap to the next line. Usually thumbnail height is more than three lines of text so there is unused space there.
I can't replicate this effect. If it is reproducible please take a look at $HOME/.config/geeqie/geeqierc.xml. The window placements and dimensions are in the layout sections at the end of the file. Please check if the dimensions are being saved correctly, or if they are saved correctly but ignored on restart.
BTW: I am using dual 4K monitors.
Here's what's going on. I start three sessions of Geeqie using the same command:
/usr/lbin/geeqie --geometry=1862x2039 . >/dev/null 2>&1 &
I get a main window of the proper size and last position and two small windows as shown here in this thumbnail:
Now, if I close the main window using [x] or Ctrl-W (I reset it from Ctrl-Shift-W) then all windows disappear but only the main window is remembered and only it is restored upon restart.
If I quit Geeqie with Ctrl-Q in any of the windows, then the layout for all three window ids are written out. The layout for the main window is:
main_window.x = "0" main_window.y = "41" main_window.w = "1862" main_window.h = "2039"
and for the two sub-windows "lw1" and "lw2":
main_window.x = "5644" main_window.y = "557" main_window.w = "1165" main_window.h = "500"
main_window.x = "5588" main_window.y = "91" main_window.w = "1165" main_window.h = "500"
When I restart Geeqie, all three windows always start up with the main window Width and Height but in their saved positions -- sort of, because if they are near the bottom of the screen, they are moved up for the larger window to be displayed.
Now, if I Ctrl-Q again, the new values for the sub-windows are saved:
main_window.x = "4474" main_window.y = "87" main_window.w = "1862" main_window.h = "2039"
main_window.x = "4204" main_window.y = "87" main_window.w = "1862" main_window.h = "2039"
Looks like a bug where the command line geometry spec is always ignored for sub-windows upon creation, defaulting to the built-in values. The saved geometry for sub-windows is also ignored from the geeqierc.xml file, but if the sub-window is defined, then it uses the main window geometry rather than the built-in values. I tried editing the saved values manually and then restarted Geeqie, and it made no difference; the main window Width and Height were used.
However, the most important thing here is to get the --geometry size and position values to always be honored, allowing programmatic control of the placement of different windows for different purposes.
The current implementation requires that a "main" window always exists - that's just the way it is.
I keep reverting to the old 1.5.1 build because this is a real problem for me. I have eight virtual Xfce "Desktops" defined and switch between them constantly. I do a lot of different graphical work and start Geeqie up multiple times on different desktops so I could have three or four sessions running concurrently. I finish a task and close Geeqie down. I have no idea which is the "main" and which are "sub" windows. (yes, I know about displaying the ids, but there is no "main" in my workflow.) I can't have all the viewers disappear on me just because I accidentally closed the wrong one. So here is a thought I have: I don't know the mechanics of this hierarchy of main-to-sub windows, but could you possibly trick the system into not displaying "main" and only displaying sub-windows, including the first one? This would place every window on an equal footing and any of them could be closed independently without affecting any other one. To make this act like the current 1.5.1 implementation, the last man (window) standing would get it's geometry saved to the geeqierc.xml file. If a "main" is absolutely required, it would be a virtual instance that the user never sees.
I don't know the underlying mechanism used by Firefox, but it operate the way I would like. All instances of Firefox have the same priority -- there is no primary or main instance. I can have multiple FF sessions running and close any of them without affecting the others, unless using Ctrl-Q, in which case all instances are terminated.
Also, the only time multiple windows are saved is when Geeqie is terminated with Ctrl-Q. Who does this? I only discovered it by accident during this testing work. When [x] or Ctrl-W are used in the main window, only the main window is saved. What would possibly be more useful would be to add a "pin" toggle (not to be confused with the Float file list pin) on the toolbar to indicate whether this particular window layout should be saved and restored when Geeqie is started. Upon start-up, Geeqie would restore the "pinned" windows, if and only if they were not already displayed (testing against ID). This would allow each user to customize the layout they preferred.
For people like me, this would be most useful if the virtual desktop target could also be remembered and restored, even if that desktop wasn't active. I know that's asking a lot. Most window managers that support virtual desktops, can't remember an properly restore app layouts across those desktops.
Tried that patch and noticed a few problems:
Thanks for trying the patch, but I have a bad feeling about any solution to this problem. (Icons cannot be used on the main menu - in fact, icons in any menu are now deprecated in GTK). The only, reasonably easy, solution is to put a scroll bar under the menu widget.
in thumbnail list view data is very long
I am not clear about the problem here. I have attached a screenshot of what I see in list view plus thumbnails:
I am not clear about the problem here. I have attached a screenshot of what I see in list view plus thumbnails:
If the date would be split into two lines then one could make this pane much narrower losing only part of the filename. However in the case of photos the name is often just a number or some form of date string, so in many cases it could be easily partially hidden without much loss.
On the other hand, maybe using narrow icon view mode would be better to have left pane as narrow as possible... Anyway, both views would benefit from possibility of customizing information that are presented. Maybe re-using code from overlay would be a solution? I.e. add two configuration options: for details displayed in list view and in icon view.
/usr/lbin/geeqie --geometry=1862x2039 . >/dev/null 2>&1 & I get a main window of the proper size and last position and two small windows as shown here in this thumbnail:
There is a commit which fixes this part of the problem: http://geeqie.org/cgi-bin/gitweb.cgi?p=geeqie.git;a=commit;h=804593cfce94eacf75cae6a2b6b792fefee8a16f