odraencoded / pynorama Goto Github PK

This should allow images from the clipboard, network, or other slow or otherwise inaccessible sources to be temporarily kept as a file

Allow dynamically adding and removing mouse handlers, album layouts, file loaders and etc.

Although it would be ridiculous to program the OCR code in this project, there must be a way to use another project or online service to allow character recognition right from the image viewer.

I want to get preference profiles implemented in the image viewer.

The idea is that this completely unnecessary feature will help further normalize the already completely unnecessarily normalized preferences subsystem.

Preferences are currently divided into two objects:

A thing
The widget that changes the thing behavior.
Plus a pair of functions to save and load the preferences for/from the thing.

My proposal is that this should be refactored to become like this:

A thing. (whatever)
An object the handles preferences for the thing. (PreferencesObject)
An widget to edit said object. (PreferencesWidget)

Once this is done the following can be done.

1. Get current PreferencesObject for a thing.
2. Detach it from a thing.
3. Get a different PreferencesObject.
4. Attach it to a thing
5. Preferences profile for a thing has been magically updated.

Allows images to be dragged from the image viewer

The current auto-zoom system reapplies itself wrongly when window has been resized but the image the auto-zoom was enabled on is no longer the focus image.

Changes must be made so that won't happen!

Currently, application wide preferences are stored with GSettings and mouse related settings are stored in XML, I don't like it so it must be changed.

First, GSettings is waaaaaaaay too obtuse for an image viewer application preferences, so it should get ridden of.

• GSchemas are type safe and need to be compiled, that does not go well with a project that is pure python.
• It is really the only reason this project uses autotools instead of a sane install script.

Second, XML is waaaaaaaay too complicated for application preferences or mouse related preferences.

• There is no way to maintain a standard or any reasoning about element names, what is attribute, what is text and what is a child node.
• I'm so not writing a schema for this, and that wouldn't even help anyway.
• It is too fat. It doesn't have tag omission like HTML.

Move everything to JSON or YAML.
Probably JSON since python has a built-in module for JSON.

So image frames have a function to render themselves. Which sounded like a great idea, except for a few factors.

• The image viewer uses Cairo.
• Literally all rendering is done in Cairo.
• Everything is rendered as a Cairo pattern either way.
• Even animated GIFs have their frames converted to patterns.

As you can see, this method has helped in literally nothing!

A better defined way of rendering must be implemented to allow image view to perform optimizations on drawing code, however, custom rendering code in views must be allowed, despite the fact I have no idea what is it ever going to be used for.

Allows ctrl+drag to act different than just a normal drag, alt + scroll wheel and et cetera

On trying to execute

 aclocal && autoconf && automake --foreign --add-missing
 ./configure && make && make install

make failed with the message

make[1]: *** No rule to make target `pynorama.in', needed by `pynorama'.  Stop.
make[1]: Leaving directory `/home/anubhav/pynorama'
make: *** [all-recursive] Error 1

But renaming pynorama.in.in to pynorama.in and running make again worked.

You should change the filename in the install scripts, or maybe rename the file itself.

Doing it will open the temp directory as an album instead

In the mouse options, it would be interesting to extend the pivot settings to include "mirrored" coordinates.

With a mirrored mouse pivot, when clicking on the top right corner of the view, for example, the pivot would be the bottom left corner. This would allow the mouse coordinates option to be meaningful in mouse handlers where it would be otherwise meaningless.

(The stretch mouse handler can't use mouse coordinates because you can't zoom out with it, only zoom in.)

Also I want to see what it would be like.

After opening an image the main window may freeze, drawing incorrectly and partially until it's resized.

Should allow for having multiple albums displayed in a single window

Somehow, GLib.utf8_collate_key_for_filename raises an UnicodeEncodeError when you try to sort filenames that have non-ascii characters.

Doesn't happen in Linux, but happens in Windows.

It doesn't work the same way with the image strip layout as it does with the default layout since it was designed in a single image use.
A new, awesomer setting must be designed to replace it.

Mouse mechanisms that need a button have a standard button widget for setting the mouse button associated with it.

Mouse mechanism that need a scroll wheel have no standard widgets. Make them.

Besides copying the current image, it would be neat if the image viewer could copy partial areas of the view marked by a selection box.

I spent a lot of time working in this whole file opening pipeline so it would be able to open an animated gif hidden inside a folder inside a rar downloaded from a link which was copied from the browser pasted on the image viewer after a series of non-blocking I/O calls, caching, and stateful recursive processing.

Turns out I need that functionality once in never. So I'm dropping it.

The whole file opening pipe line will be redesigned for the third... or fourth time? I don't know, I lost count. Let's hope I get it right this time.

This time focus will be given on removing useless classes and generic functionality. Turns out being generic doesn't pay out, and only serves to create a convoluted mess that can't be managed or worked on.

When this issue is marked as fixed there better be less lines of code in this thing than there were when it was created.