Skip to main content

Poll

How do you like the blog of Frans?

Love it
Hate it
Didn't know/don't care about it
Who is Frans?
Beer option
Topic: Commentations on the blog of Frans (Read 4078 times)

Re: Commentations on the blog of Frans

Reply #25
safe across updates
Randomly loading a file the way you proposed isn't very safe. :-)

By the way, also camelCase is superugly.
I'm not a fan either. But it does serve a practical purpose, at least in KOReader. this_is_a_variable and thisIsAFunction so you can see it at a glance.

Re: Commentations on the blog of Frans

Reply #26
safe across updates
Randomly loading a file the way you proposed isn't very safe. :-)
I meant the file should be safe, so I would not have to re-apply my customisations after every update. Even Emacs can do it. If the upgrade is not backwards-compatible, treat the configfile as erroneous and load the defaults, which is probably safe enough.

Indeed not very hygienic when there is a proliferating culture of sharing customisations and you don't always read through every bit of code properly, but good for customisability and contributions from wider user base.

By the way, also camelCase is superugly.
I'm not a fan either. But it does serve a practical purpose, at least in KOReader. this_is_a_variable and thisIsAFunction so you can see it at a glance.
Yet you still prefix every function literally with function or function() which defeats the purpose of the naming convention. The use of camelCase causes headaches like ShowBookmap versus ShowBookMap, for example.

Re: Commentations on the blog of Frans

Reply #27
Yet you still prefix every function literally with function or function() which defeats the purpose of the naming convention.
Hardly, then you'd have to go looking for the definition every time you see it. :)

Re: Commentations on the blog of Frans

Reply #28
Kongratz on another Koreader release. Are there any plans of moving the project to Gitlab perhaps?

Re: Commentations on the blog of Frans

Reply #29
Not at this time.

Re: Commentations on the blog of Frans

Reply #30
Finally I got some code to work that takes me from page search to file search in Koreader.

I now have these buttons in readergoto.lua
Code: [Select]
        buttons = {
            {
                {
                    text = _("Skim"),
                    callback = function()
                        self:close()
                        self.skimto = SkimToWidget:new{
                            document = self.document,
                            ui = self.ui,
                            callback_switch_to_goto = function()
                                UIManager:close(self.skimto)
                                self:onShowGotoDialog()
                            end,
                        }
                        UIManager:show(self.skimto)

                    end,
                },
                {
                    text = _("Go to page"),
                    is_enter_default = true,
                    callback = function()
                        self:gotoPage()
                    end,
                }
            },
            {   
                {
                    text = _("Bookmarks"),
                    callback = function()
                        self:close()
                        UIManager:broadcastEvent(Event:new("ShowBookmark"))
                    end,
                },
                {
                    text = _("Go to %"),
                    callback = function()
                        self:gotoPercent()
                    end,
                }
            },
            {
                {
                    text = _("Table of Contents"),
                    callback = function()
                        self:close()
                        UIManager:broadcastEvent(Event:new("ShowToc"))
                    end,
                },
                {
                    text = _("Book map"),
                    callback = function()
                        self:close()
                        UIManager:broadcastEvent(Event:new("ShowBookMap"))
                    end,
                }
            },
            {
               {
                    text = _("File search"),
                    callback = function()
                        self:close()
                        self.ui:showFileManager()
                        self.ui:handleEvent(Event:new("ShowFileSearch"))
                    end,
               },
               {
                    text = _("Open previous file"),
                    callback = function()
                        self:close()
                        UIManager:broadcastEvent(Event:new("OpenLastDoc"))
                    end,

               }
            },
            {
                {
                    text = _("History"),
                    callback = function()
                        self:close()
                        UIManager:broadcastEvent(Event:new("ShowHist"))
                    end,
                },
                {
                    text = _("Cancel"),
                    callback = function()
                        self:close()
                    end,
                }
            },
The File search button took me months to get right, but it's working now.

The only issue is that, after switching to the File search dialog, you have to press Cancel twice to dismiss the File search dialog. For some reason a single press of Cancel won't work. But this is an ignorable little problem, not too frustrating.

Edit: Hah, and I found what fixes it. In the above code, I replaced UIManager:broadcastEvent(Event:new("ShowFileSearch")) with self.ui:handleEvent(Event:new("ShowFileSearch")) and now the File search dialog does not require two-times Cancel to cancel.

As a result, also my changes of filemanagerfilesearcher.lua started working (i.e. I added buttons for "Open previous file" and "History"):

Code: [Select]
        buttons = {
            {
                {
                    text = _("Cancel"),
                    callback = function()
                        UIManager:close(self.search_dialog)
                    end,
                },
                {
                    text = _("Home folder"),
                    enabled = G_reader_settings:has("home_dir"),
                    callback = function()
                        self.search_value = self.search_dialog:getInputText()
                        if self.search_value == "" then return end
                        self.path = G_reader_settings:readSetting("home_dir")
                        self:close()
                    end,
                },
                {
                    text = _("Current folder"),
                    is_enter_default = true,
                    callback = function()
                        self.search_value = self.search_dialog:getInputText()
                        if self.search_value == "" then return end
                        self.path = self.ui.file_chooser and self.ui.file_chooser.path or self.ui:getLastDirFile()
                        self:close()
                    end,
                },
            },
            {
                {
                    text = _("Open previous file"),
                    callback = function()
                        UIManager:close(self.search_dialog)
                        UIManager:broadcastEvent(Event:new("OpenLastDoc"))
                    end,

                },
                {
                    text = _("History"),
                    callback = function()
                        UIManager:close(self.search_dialog)
                        UIManager:broadcastEvent(Event:new("ShowHist"))
                    end,
                },
            },
        },

This latter file also needs to have this line at the top: local Event = require("ui/event").

I still really don't like Lua. I do not like any programming language that requires curly braces and on top of that more sets of braces. Also all languages that are ultra-touchy on commas have certainly been created for the purpose of maximising the torment of souls.

Re: Commentations on the blog of Frans

Reply #31
Has anybody floated the idea of a scrollbar for reader view in Koreader?

(The scrollbar should be optional of course, duh.) I'm one who is scrolling by approximately half-pages when reading a pdf/djvu, but I often find myself wanting to scroll with better precision. When I read prose in text editors on computer, I often set the (sub-)heading or top line of a paragraph to the top edge of the screen/viewport. I wish this were somehow available with Koreader also.

So, my wishful thinking proposes that a tap at or swipe from the right edge of the screen would bring up a scrollbar along the edge about as feature-rich as in modern web browsers and IDE's. Then let's say a tap on the scrollbar would mark the spot that should instantly fly to the top edge (or, when in comic-book mode, it would depend on the scrolling direction) when viewing a pdf/djvu.

The skim widget, book map and page browser in Koreader neatly serve as the equivalent of minimap in modern text editors (like Overview plugin in Geany). This helps browsing across the pages of the document and therefore the book map and page browser would appropriately be accessible from scrollbar. Access to notes and highlights from the same would also be nice.

Then there's the fulltext search. In modern web browsers, the scrollbar indicates matches for text search. I don't think this can be productively replicated for the scrollbar in Koreader, but perhaps there is a way to add a separate view to display all search matches found in a file (similar to the way grep displays results or Occur in Emacs). This kind of view for search matches should be doable for epubs at least.

What is still missing in Koreader is an aid to navigate a single elaborate page, let's say a comic book page or a page of yester-millennium's newspapers. The column mode was a very welcome addition, but Koreader does not have the capability to start reading at an arbitrary spot in the middle of the page or to preserve an arbitrary spot to go to it when the file is later revisited from history. Pocketbook's reader app always had this capability, to zoom and drag the page in arbitrary directions, and I always liked Pocketbooks for this reason.

I understand it may not be feasible to implement in Koreader the ability to start reading at an arbitrary spot and to drag a zoomed page in arbitrary directions. It's just my wishful thinking. (Pocketbook's reader actually lags, struggles to load and displays belatedly when used this way.)

Re: Commentations on the blog of Frans

Reply #32
Free dragging isn't that hard in principle, but what I like most is not having to do it. That is, I'm not overly interested in spending time implementing it at this time, and apparently other people aren't either.

Re: Commentations on the blog of Frans

Reply #33
Free dragging isn't that hard in principle, but what I like most is not having to do it.
I don't like to drag either, not even in continuous mode. My number one preference among my suggestions is the ability to select a point that would become the next point at edge. Something like next half-page, but with fine-tuning on the fly at each turn.

It would make sense for pdf/djvu but likely not epubs, so it is of limited utility. And I'm okay if it is never implemented.

Re: Commentations on the blog of Frans

Reply #34
I don't like to drag either, not even in continuous mode.
I explicitly renamed it from its prior name "scroll mode" because I strongly dislike the suggestion that there should be any scrolling/dragging involved. In extremely rare circumstances I might reposition.

Anyway, it means it's somewhat unlikely to come from me, but of course anybody who's interested is free to try their hand at an implementation.

Re: Commentations on the blog of Frans

Reply #35
In extremely rare circumstances I might reposition.
I guess it's my personal problem that I reposition a bit too much and also zoom now and then. For example when looking at some printing quirks in old books and overwrites in ancient manuscripts. In pdf/djvu files made of them, that is.

It's okay. Koreader can't be good for everything. Let some other reader apps have a job too.

 

Re: Commentations on the blog of Frans

Reply #36
In Koreader, there's a menu setting for Links: "Ignore external links on tap". This is a sane option for those who don't want to accidentally end up all over internet.

Then again, I recently managed to get Koreader's Newsdownloader working and I noticed that it epubifies webpages. Very nice :up: So, wouldn't it be awesome to have another menu option for Links: Epubify ???

Perhaps it is possible to include in Newsdownloader a way to epubify a user-typed direct webpage url. In fact, I have been looking into its source code and I think all the elements are there. If this has not been done already in some hidden way, maybe I can give it a go as a little Lua exercise.

Edit. Okay, the fruit of the day: rgrep --color -nH --null -F "createEpub" .
Code: [Select]
./base/build/x86_64-linux-gnu-debug/plugins/newsdownloader.koplugin/epubdownloadbackend.lua199:function EpubDownloadBackend:createEpub(epub_path, html, url, include_images, message, filter_enable, filter_element)
./base/build/x86_64-linux-gnu-debug/plugins/newsdownloader.koplugin/epubdownloadbackend.lua200:    logger.dbg("EpubDownloadBackend:createEpub(", epub_path, ")")
./base/build/x86_64-linux-gnu-debug/plugins/newsdownloader.koplugin/main.lua551:        DownloadBackend:createEpub(news_file_path, html, link, include_images, article_message, enable_filter, filter_element)
./base/build/x86_64-linux-gnu-debug/plugins/newsdownloader.koplugin/main.lua576:        DownloadBackend:createEpub(news_file_path, html, link, include_images, article_message)
./frontend/ui/wikipedia.lua649:function Wikipedia:createEpub(epub_path, page, lang, with_images)
./frontend/ui/wikipedia.lua1372:-- Wrap Wikipedia:createEpub() with UI progress info, provided
./frontend/ui/wikipedia.lua1374:function Wikipedia:createEpubWithUI(epub_path, page, lang, result_callback)
./frontend/ui/wikipedia.lua1382:        -- If errors in Wikipedia:createEpub(), the coroutine (used by
./frontend/ui/wikipedia.lua1386:        local ok, success = pcall(self.createEpub, self, epub_path, page, lang, true)
./frontend/ui/wikipedia.lua1391:            logger.warn("Wikipedia.createEpub pcall:", ok, success)
./frontend/ui/widget/dictquicklookup.lua346:                                    Wikipedia:createEpubWithUI(epub_path, self.lookupword, lang, function(success)
./plugins/newsdownloader.koplugin/epubdownloadbackend.lua199:function EpubDownloadBackend:createEpub(epub_path, html, url, include_images, message, filter_enable, filter_element)
./plugins/newsdownloader.koplugin/epubdownloadbackend.lua200:    logger.dbg("EpubDownloadBackend:createEpub(", epub_path, ")")
./plugins/newsdownloader.koplugin/main.lua551:        DownloadBackend:createEpub(news_file_path, html, link, include_images, article_message, enable_filter, filter_element)
./plugins/newsdownloader.koplugin/main.lua576:        DownloadBackend:createEpub(news_file_path, html, link, include_images, article_message)

So it looks like those EpubDownloadBackend:createEpub and DownloadBackend:createEpub bits in Newsdownloader files are the generic epubification function~command that I am looking for. And I discovered that when Links / Ignore external links is not set, then we get a popup prompt, which could sensibly include the "Epubify" button. How about it?

Re: Commentations on the blog of Frans

Reply #37
Perhaps if you float the idea on the Gitter chat, ping roygbyte.