Already set screenshot filename about lximage-qt

[jleclanche]

To be honest I think regardless of whether we move screengrab or not, lximage-qt's screenshot functionality makes no sense...

[jleclanche]

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]

@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:

1. The preview functionality is really bad. Opening the full lximage-qt image view just to see whether the screenshot you took is acceptable... not a good idea.
2. lximage-qt screen area shot is noneditable; Screengrab's can be modified after-the-fact (although there's serious bugs when a dropdown window is open, that remains to be fixed).
3. There has to be a default mode where you hit print screen and the screenshot is ready. This comes back to 1.
4. Screengrab has a really cool "snap to border" function which was merged in recently. It needs some extra work I believe but it's super useful.

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.

[tsujan]

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.

I was able to take screenshots by pressing the print button

That's probably not lximage-qt. It may be scrot or another screenshot utility. However, lximage-qt -s serves as a screenshot tool too.

[tsujan]

By the way, your installed version of lximage-qt is too old.

[Serkan-devel]

I'm using the stable repositories and lximage-qt -s gives me the same result

[agaida]

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.

[tsujan]

@agaida What about adding more (command-line) options to lximage-qt to save screentshots inside a folder defined by the user, with date/time as name? The screenshot capability of lximage-qt is already great, after @selairi's work (#86).

[tsujan]

I'm using the stable repositories....

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.

[tsujan]

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 ;)

[agaida]

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 ...

[jleclanche]

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.

[agaida]

also true

[tsujan]

... lximage-qt's screenshot functionality makes no sense...

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.

[tsujan]

@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.

[jleclanche]

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.

[tsujan]

It could also be a good password manager and app launcher and still remain lightweight...

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.

[tsujan]

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.

[jleclanche]

If it weren't for the relation between taking screenshots and showing images, I wouldn't say that.

But what's the relation exactly? In the code they're completely distinct... Why keep them together?
FWIW I have nothing against a lxscreenshot utility replacing screengrab.

[Serkan-devel]

Dividing the code into a front- and backend seems logical to me.

[agaida]

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.

[tsujan]

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.

[tsujan]

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.

[Serkan-devel]

How do I enable popularity contest on my device?

[tsujan]

Or zoom the screenshot, or save it somewhere else, or.... more examples come to mind.

[agaida]

@Serkan-devel sudo dpkg-reconfigure popularity-contest

[jleclanche]

@tsujan to be clear I have no horse in the "one vs. two binaries" race, I just care about retaining screengrab's good functionality.

[tsujan]

@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!

[jleclanche]

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

[tsujan]

Oh, that's outside my expertise! I care for codes and don't like feature removal.

[jleclanche]

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...

[tsujan]

I'd really appreciate your help in restoring screengrab's featureset in lximage-qt...

Really like to do so. Believe me: time is scarce.

which means lximage-qt will be the redundant one

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.

[jleclanche]

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.

[agaida]

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.

[agaida]

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