You are not logged in.
I recently released the first considered stable version of my project. It is is similar to sxiv or feh and based on pim, but includes a few different features I wanted.
Vim-like keybindings
Thumbnail mode
Simple library browser (browse through folders and open images)
Basic image editing (rotate, flip, brightness,...); changes can be applied to the file
Slideshow mode
Search directory recursively for images
It was written in python3 using Gtk3 via python-gobject, so the dependencies are rather heavy. I need Gtk3 anyway so it isn't an issue for me, but I see why it might be one.
Currently vimiv is available via github:
https://github.com/karlch/vimiv
Further information is available on the github page and full documentation is in the included man-page.
I am working on a PKGBUILD and will open a thread asking for help on that. If all goes well, vimiv will be in the AUR soon.
EDIT: vimiv is now available in the AUR:
https://aur.archlinux.org/packages/vimiv-git/
Any type of feedback is highly appreciated as this is my first actual project
Last edited by karlch (2015-12-02 22:53:40)
Offline
I have just installed it and 'til now like it, however there are a few issues:
I have been unable to open any file from the command line using the syntax `vimiv file'
The first time I started it (without any parameter) nothing further happened and it became unresponsive at CTRL-Q (XFCE asked me to kill it).
However this issue has never appeared later.
And some suggestions:
It would be nice, if the "simple library browser" would distinguish somehow between folders and images.
Also, it would be more convenient, if the browser would resize according to the length in the current directory
Something like ".." to get in the parent directory
a bigger default window size
resizing the window to the size of a new opened image, when possible
hjkl in the library browser
Note that I haven't really tested any of the features that go beyond starting the program and using the arrow keys and the enter key, so I can't really say much about how I like it, though the manpage looks promising.
More:
When hitting 'f' in the file browser I get the other (blank) window as fullscreen
Pressing a key without a specific function prints errors to the console.
Last edited by respiranto (2015-12-02 23:27:16)
Offline
Thanks for your feedback, I will reply one by one:
Are there any errors, I have never seen that issue ever before...
Another issue I haven't seen, errors would be very helpful
That sounds like a good idea, I will work on distinguishing them next
You mean the height, right?
Do the keybindings "u" or "h" not do what you want
Since you are using XFCE put the option "tling_wm" to False, the default will now be larger and you can also set the geometry yourself
Vimiv tries to size the image to the window, not the other way round as I use i3, a tiling wm. I don't plan on implementing that anytime soon
Works for me, the keys should be like in ranger if you are familiar with that
EDIT: More
I don't have any of these issues either, I might install XFCE tomorrow and do some extra testing
EDIT2: I see what you mean with f now, missunderstood you, thanks
Last edited by karlch (2015-12-02 23:30:19)
Offline
I am going to number the issues now, to prevent chaos.
Old (Be this list 0)
`vimiv file':
I am getting this error on the bottom of the main window:
No valid paths. Opening Library viewer.
By the way, the time this error is displayed is about three seconds - not that much time to read, nor to copy.
Update: It works only with files in the current directory, which may be speicified with a long path though e.g., ../curdir/file or an absolute path.
--
Freezing at first start:
I have been able to reproduce this right now.
It seems like it always happens when vimiv is started the first time after reboot.
The only error I get is "Killed" after I allow xfce / xfwm? to kill it as it suggests me.
However even this error is from the shell, I assume.
--
Distinguish images and directories in browser: Great!
Resizing the browser for very long filenames: No, I mean the width - but I see that you probably don't want that, since you use a tiling-wm.
".." directory entry: As I said, I did not read through the whole manpage, so thank you for the hint.
Though I still think ".." is a good alternative option, so your program would also be usable without having read its manpage.
Small window: Thank you, that solved it. Maybe that configuration is worth a message in the post_install()?
Resizing the window according to picture: OK, I can live with that, probably I will also switch to a tiling WM someday.
It should be possible to mimic this feature with a small bash function, using ImageMagick's identify command and your --geometry option.
Unfortunately I can't test this, since opening a file from command line does not work for me.
'hjkl' in library browser: Yes, it does work, probably I simply was confused by the long time it sometimes takes.
However I again have the impression, that 'j'/'k' take a little longer to trigger the action than the arrow keys do
and more importantly 'j'/'k' does not care about movement with the arrow keys, while the arrow keys do care about the previous movements with 'j'/'k'.
Pressing a key without a specific function:
It seems like it's actually rather some of those with a function:
Pressing 'j'/'k', does not apply to 'h'/'l':
Traceback (most recent call last):
File "/usr/bin/vimiv", line 1014, in handle_key_press
funk(*args)
File "/usr/bin/vimiv", line 149, in scroll
self.library_scroll(scrolltype, horizontal)
File "/usr/bin/vimiv", line 178, in library_scroll
self.num_clear()
File "/usr/bin/vimiv", line 795, in num_clear
self.update_info()
File "/usr/bin/vimiv", line 620, in update_info
name = self.paths[self.index].split("/")[-1]
IndexError: list index out of range
Pressing 'g':
Traceback (most recent call last):
File "/usr/bin/vimiv", line 1014, in handle_key_press
funk(*args)
File "/usr/bin/vimiv", line 759, in move_pos
current = (self.index) % len(self.paths)
ZeroDivisionError: integer division or modulo by zero
Pressing 't':
Traceback (most recent call last):
File "/usr/bin/vimiv", line 1014, in handle_key_press
funk(*args)
File "/usr/bin/vimiv", line 561, in thumbnail_toggle
self.thumbnails()
File "/usr/bin/vimiv", line 539, in thumbnails
self.togo = [(self.index) % len(self.paths)]
ZeroDivisionError: integer division or modulo by zero
...
New (be this list 1):
Important: /etc/vimivrc.py should be in the backup array in your PKGBUILD, so it won't be overriden automatically on upgrade.
If I try to quit the program with CTRL-C, nothing happens, but as soon as vimiv's window gets focus again, the following is print to the console:
Traceback (most recent call last):
File "/usr/bin/vimiv", line 995, in handle_key_press
def handle_key_press(self, widget, event):
KeyboardInterrupt
If I am in the /home directory and hit 'u'/'h', the program freezes - no error anywhere.
However this is again not reproducible, though it still takes about three seconds.
/home is on a separate partition, if that matters.
I generally have the impression, that switching folders takes longer than it should.
It would be nice if an error would be displayed, when one attempts to enter a not readable directory.
The same applies to images, though I have not tried that.
Just like with ranger, it would be nice if the browser remembered the previous location in the directory.
Another suggestion: left & right keys as synonyms for 'h' & 'l'
vimiv(1) - s/Delte/Delete/
Another suggestion: When the browser has focus, let g and G change selection, not the image in the main window.
Alternatively, if you want any key always having the same meaning - and always doing the that, one could consider implementing this with another key.
Another problem: If I am in the browser, at position 2, which is the first image, i.e. at position 1 is a folder, the picture opened upon pressing enter is the alphabetically second one.
Last edited by respiranto (2015-12-03 15:58:44)
Offline
First of all thank you so much for this!
List 0
Should be solved, only happened with single files
I am afraid as long as I don't know why this happens I cannot solve it...
On my working list
Sounds like something I could do, it is also a popup in tiling wms
I find h or now "Left" more intuitiv and I do not remember keystrokes except for numbers so this isn't very straightforward. Therefore not quite yet.
Will edit the PKGBUILD completely when I have time
Okay, good
Should be solved now, I cannot reproduce the "lag" though.
I see the issue, it only appears when no image is open as it tries to scroll it. Will find out why and solve that soon.
List 1
As I said, I will work on the PKGBUILD.
Ctrl-C is interpreted by python as keyboard Interrupt, I guess I could catch that exception.
Known issue, I think I might block going up from /home as I don't find it very logical to take a look at pictures somewhere else.
Sounds like something smart to do.
Another thing, but a bit more complicated, added it to my TODO list.
Done
Thanks for pointing the typo out!
Will change the behavior of "g" and "G" in both the library and when in thumbnail mode
I know why and I think I will be able to solve this very soon
All in all, I am looking forward to some coding over the week-end
Offline
Thanks for all the effort.
I think it's a really nice program which will probably replace the one that I have installed as part of the XFCE group.
To point 1.3:
I don't consider that a good idea, for example I might want to access the Arch logos, supplied by archlinux-artwork, which are stored in /usr/share/archlinux/logos/ .
Be sg a shorthand for suggestion respectively feature request.
List 2:
sg: implement a feature that allows opening by filename / changing to directory from within vimiv by typing the absolute or relative path
I was a little surprised that the new version string indicates the new package being older than the one installed before. Is this correct?
sg: ability to set the zoom to 1 (and possibly to other, to be specified values).
sg: `vimiv <folder>' to open the library browser showing <folder>.
sg: I don't know if that is realizable, but could the space behaviour be changed, so that it will 'pause' the animated image instead of simply showing its 'begin'?
sg: make CTRL-Q behave in the same way as 'q', i.e. quit the whole application.
sg: `mv /etc/{vimiv/,}vimivrc.py' unless you plan to put further configuration files under /etc .
Last edited by respiranto (2015-12-04 13:55:47)
Offline
First of all thank you so much for this!
Known issue, I think I might block going up from /home as I don't find it very logical to take a look at pictures somewhere else.
/media/.
I rest my case.
Offline
I was a little surprised that the new version string indicates the new package being older than the one installed before. Is this correct?
Nope, it is not, this must be because my pkgver does not work correctly (yet) as Scimmia pointed out.
/media/
q.e.d., you are right
I did some of the quicker bugfixing just now, expect a major update after the week-end
Offline
As promised, version 0.2 is now out.
List 0 should be done except for the 2 which I still cannot reproduce and 4, 5 which I won't implement.
List 1 should be implemented completely
List 2 should be done except for 5 which I still haven't been able to implement and 7 because it violates the arch packaging standards which say:
/etc System-essential configuration files
https://wiki.archlinux.org/index.php/Ar … _standards
Additionally one can run external commands and marking images became much more useful.
Again, please refer to the manpage for further info
EDIT: typo
Last edited by karlch (2015-12-06 18:57:35)
Offline
Thanks, great work!
Some other points (List 3):
When resizing the browser, so that the size is a little less than necessary to show everything, the filename column sometimes is too small to hold the full filename.
I assume this to be a font issue, since it does not work with my default font, DejaVu Sans Book, while it does work with e.g. Cantarell.
Can this be fixed so that it works independently of which font is used?
--
sg: I basically like the idea of a partially hidden filename - in case the space is to small, so that all columns are always (except for very thin windows) visible.
Offline
I don't know what you mean exactly, what happens then? Is there no filename at all or are the other columns not visible?
That is the way I wanted it to behave, I just didn't consider that people might want to make the window smaller. I changed one parameter, it works for me (also with DejaVu Sans Book).
Offline
I see only a part of a filenname, see this screenshot
The problem is, that it does not work always, i.e. if I have long filenames like in the above screenshot, the later comlumns are not fully shown.
Offline
Yep, the partial filename is how it is supposed to look
But it is also supposed to always show all columns... Have you upgraded since your last post?
Offline
I have the latest version, r41.597246c-1.
Offline
I am afraid that isn't the latest version on github, according to Trilbys words in the PKGBUILD thread I will not keep the version info in the AUR website up to date if I do not have to edit the PKGBUILD.
Last edited by karlch (2015-12-06 19:25:15)
Offline
Sorry, I didn't know that "changing one parameter" meant that you already published it on github.
And I forgot again about pkgver()...
It works fine now, thanks!
EDIT 0: By the way, what has happened to the tiling_wm setting?
I see it has been removed from the default vimivrc.py and has no effect disregaring whether it's True of False.
EDIT 1: I actually never changed the width for the screenshot above, though that is no longer important now.
Last edited by respiranto (2015-12-06 19:34:27)
Offline
No problem, glad it works
I managed to have a working setup for tiling and stacking window managers without the setting, makes life easier and is much cleaner.
Offline
Another point:
If I open vimiv without parameter and don't choose a filename within about 5 seconds, the title bar of the main window shows:
"vimiv No open images"
where vimiv is there by default, which is probably related to my wm.
Is this intented?
To me it looks not so nice and does not inform me about anything that I don't know yet.
I just realized that 2.6 is still "unsolved". Do you plan to do so?
Actually it does not matter much to me, but it would be nice though, since some applications can only be quit by CTRL-Q, so I might be tempted to use it for vimiv, too.
Last edited by respiranto (2015-12-06 19:43:08)
Offline
I don't ever see my titlebar so I just did what I found easiest, let it display vimiv + the current statusbar message. What would you suggest for the titlebar or would you only remove this specific message?
It is unsolved? Does your wm parse Ctrl-Q somehow? It works fine for me and it is bound to the same function as "q"... (lines 55, 56 if you are interested).
EDIT: It also works in vanilla xfce4 for me.
Last edited by karlch (2015-12-06 19:55:59)
Offline
During the first 5 seconds, the status is only shown on the bottom of the main window, then also on the titlebar.
So I would suggest to either
- not show any status message in the titlebar unless it is the name of the current image or
- to never show any status message in the titlebar, if this is easier.
CTRL-Q:
I don't know, whether xfwm acts upon CTRL-Q by itself, but it's possible.
As far as I understand the code, "^q" does only "quit" the current window - (it)self.
If I recall correctly, there is a way in GTK, to make a window something like a subwindow.
Is this the way you created the file-browser?
on your EDIT:
You are right, I just tested with a new user and will now try to find out the responsible setting.
EDIT: It's the "close window" setting. It is by default Alt-F4 in XFCE.
So it seems to make sense now.
Though I am a little surprised, that in GIMP, closing the main window, also by CTRL-Q, quits everything.
Last edited by respiranto (2015-12-06 20:21:23)
Offline
That was because the first one was handled as error message (those are always displayed for 5 seconds and nothing else) and the second one as status message. Should be solved now.
Actually both call the function quit which quits the Gtk Main loop, so all images are closed.
The file-browser receives the popup-role, so I guess one could call it a subwindow.
That setting makes perfect sense. The reason why all other windows are also closed when the main window is killed, regardless how, is because I can connect to the "destroy" event of that window. Obviously doing that for subwindows would not be a good idea
I suspect this is also how Gimp handles this.
Offline
OK, thanks.
I thought that calling CTRL-Q always killed only the active window, but seem to have been wrong.
Offline
Still liking your program, though some more suggestions:
List 4:
For each flag that enables something ('-b', '-f'),
add a flag that disables this feature, e.g. '+b', '+f'.
Is there a reason not to use `make DESTDIR="$pkgdir" install' in package() ?
Offline
Glad you still like it
4.1 Shouldn't be very difficult, I can surely implement this soon.
4.2 yesish, I tried doing it with make and it didn't work. Just tried it now, it works. Must have been a typo of some sort... Sounds like a good idea, will change that.
I am currently working rather hard on version 0.3, so I will just add those to changes to my todo list there.
Mainly I will put it all into one single window, the popups don't seem to make much sense if I can just use a split (e.g. like NerdTree) for the library and a small bar for the manipulations. Catching some more exceptions and making the manipulations more responsive are the other things todo.
Last edited by karlch (2015-12-13 19:46:50)
Offline
Great, looking forward to v0.3 !
In particular, I like the idea of removing the popup windows, though catching exceptions is always a good idea.
However, I use it mainly for viewing images, so I have not had any error printed since my last post nor any issues with manipulations.
Offline