Already set screenshot filename #118
Comments
|
You're right: the name should not be blank. The file save dialog should be equipped with an appropriate name -- perhaps, the current date and time.
That's probably not lximage-qt. It may be scrot or another screenshot utility. However, |
|
By the way, your installed version of lximage-qt is too old. |
|
I'm using the stable repositories and |
|
btw - @jleclanche had a interesting suggestion, see lxde mailing list. Take over screengrab from Qt-Desktop and improve it - it make no sense to implement some things double. Ok, the codebase of screengrab need a little cleanup and polishing, but imho we should go that way: split viewer and screenshot utility would make sense. So i would like to put this on hold. |
V0.5.1 doesn't include important commits. The latest stable is 0.6.0 but it needs the latest libfm-qt. However, that may not be related to this report. |
|
IMHO, although lximage-qt is given nice features recently, it not only has hidden potentials but also needs to be polished. I haven't had much time to work on it as I wanted but will try to do so in future, although I don't know how to find the needed time ;) |
|
To be honest I think regardless of whether we move screengrab or not, lximage-qt's screenshot functionality makes no sense... |
|
anyways - what ever improve the situation is welcome - i'm a little bit biased. It is only a wild guess, but i think that our codebase is cleaner. So if it is less work to pimp up lximage-qt than to rework screengrab ... |
|
At the end of the day, someone needs to step up to do the work, whether that work is taking screengrab and cleaning it up or ripping the lximage-qt code into its own app and making that the new screengrab. This is all theoretical unless someone is up for it. |
|
also true |
I can't agree. I don't say that I'll prove the opposite -- because I might not find the required time -- but, as mentioned above, it has many potentials waiting there to be actualized. |
|
I have nothing against the functionality itself (it's the same as screengrab's). I'm saying it makes no sense to have in lximage-qt. |
|
@jleclanche I understand your point of view. Yes, lximage-qt is an image viewer. However, it can also be a good screenshot utility and remain lightweight. |
|
It could also be a good password manager and app launcher and still remain lightweight... Point is that right now, we have two apps with two code paths, two different but converging featuresets. This spreads both us and our users thin; I think this is a fairly low hanging fruit. The end goal being: We have one image viewer and one screenshot app. |
No! If it weren't for the relation between taking screenshots and showing images, I wouldn't say that. They are related and lximage-qt can already take screenshots. It just needs to be made better. As for the end goal, it can be a single app that can do both jobs.... It depends on the point of view. Some distinctions are arbitrary. |
|
Anyhow, if I work on lximage-qt, I'll do as I said above. Someone might want to create a separate screenshot utility and I respect that but it doesn't mean removing or not improving the current functionality of lximage-qt. |
But what's the relation exactly? In the code they're completely distinct... Why keep them together? |
|
Dividing the code into a front- and backend seems logical to me. |
|
some statistics might help https://i.imgur.com/Uh0pu1d.jpg - and the question about one or two binaries from the same codepath is right now a little bit bike shedding. Ok, i would prefer two separated binaries. |
|
This would be a long discussion that could go nowhere -- like separating the desktop functionality of pcmanfm-qt from it. Previously, I thought they should be separated; now I think they shouldn't. When I can't agree with myself in the long run, what could I say about our disagreement on this? ;) I think a unified lightweight app is always better than dividing because the parts couldn't see each other and so, couldn't use their separate functionalities -- redundant code and duplications would be needed for that. |
|
As just one simple example, you might want -- for whatever reason -- rotate a screenshot. With lximage-qt, that's possible and it isn't a good idea to duplicate the code anywhere else. Deja vu?! I feel we had similar discussions before. |
|
How do I enable popularity contest on my device? |
|
@agaida thanks for that graph, that's pretty interesting. Anyway, as you said, separate binaries is bikeshedding but my goal here isn't that, it's to figure out what happens to Screengrab. @tsujan I went into this with the mindset that we would retain and clean up screengrab. If we retain lximage-qt we have a lot of work to do here:
I don't know exactly why you see a relation between taking a screenshot and viewing an image. If by that you mean the relation between "previewing a screenshot you just took" and "viewing an image", then yes there is one, but it's very tangential: QGraphicsView does 100% of the work. 99% of the lximage functionality is useless: multi-format support, gallery view, etc. "Rotating" a screenshot isn't something that really comes up and if it does, you need to be able to fully edit the image anyway (Which is why Screengrab has an "edit in" menu). A much more likely scenario is you just took a screenshot and want to black out private information / highlight relevant information, none of those things can be done in lximage-qt. I'm being practical here, I've used both. |
|
Or zoom the screenshot, or save it somewhere else, or.... more examples come to mind. |
|
@Serkan-devel sudo dpkg-reconfigure popularity-contest |
|
@tsujan to be clear I have no horse in the "one vs. two binaries" race, I just care about retaining screengrab's good functionality. |
|
@jleclanche I just mean it isn't good to remove any code or not improve it in lximage-qt. Why should I be against a separate screenshot utility if people like it and there are enough devs that could work on it? All that I say: OK, make it but please do not remove lximage-qt's functionality from it! |
|
I think you're missing my point here. The original email I sent: https://sourceforge.net/p/lxde/mailman/message/36089533/ The situation right now: We have two utilities that take screenshots and have different featuresets. We have developers working on both and are spreading ourselves and our users thin because of that. The situation in an ideal world: We have one utility that takes screenshots and lives in the LXDE org. I want to shut down QtDesktop as I highlighted in the email; but first, this situation needs to be figured out. I don't think this is the right github issue to do so either, I opened one here a while back: lxqt/screengrab#42 |
|
Oh, that's outside my expertise! I care for codes and don't like feature removal. |
|
If you don't like feature removal and this is the road you want to take, I'd really appreciate your help in restoring screengrab's featureset in lximage-qt. If not, the more likely scenario with no maintainers stepping up is that Screengrab will be moved to lxqt which means lximage-qt will be the redundant one as it's the one with less features... |
Really like to do so. Believe me: time is scarce.
Whether the label of "redundancy" will be attached to it or not, people have worked on its screenshot functionality and might improve it. Feature removal reminds me of the Gnome trend. I'm simply against it but will respect any decision that might be taken. |
|
This isn't meant to be feature removal, it's meant to be consolidation of two redundant features... I'm really not sure how that can be more clear. |
|
ok, maybe a remark from the packagers point of view - lximage-qt should be in the recommends or dependencies for a full LXQt installation - and as the graphic says it gained traction. So a screenshot functionality in lximage-qt will probably reach more users without additional efforts. And i'm all for feature consolidation. |
|
if we consider screengrab superior and to be the upcoming default we should not put more work than needed into lximage-qt - esp not into the screenshot functionality. Right now making screenshots in screengrab and open them in lximage-qt works perfectly fine, even the upload from lximage-qt works well - we should tighten both applications and functionality. Closing this now |
After taking a screen shot and hitting OK, an image viewer appears with the unsaved screen shot.
After selecting save, there is a file-save dialog on which the filename is blank.
Expected Behavior
I was able to take screenshots by pressing the print button and it directly saved it with time stamp as filename and with not dialog window as seen here #91 (comment) . The only issue there was, that it only saved to the home directory and not the one for images.
Current Behavior
It now takes more steps to do the same action as before.
Possible Solution
Is there a command I could utilize on lximage-qt that can set date and time within the command as before and to customize the global key shortcuts?
Context
I'm currently putting effort in naming each and every screenshot by hand, which is slower and cumbersome.
System Information
The text was updated successfully, but these errors were encountered: