Touch Kobo Touch future firmware feature request thread

[Xennex1170]

Originally Posted by BensonBear

Why? I don't see the point of discussing this. Details of the hardware and software do make a big difference on how this would be done and what it would look like, and we (at least I) don't know the details of this hardware so as I said we are just speculating.

It's not so much the discussion as you seem to have no idea of the difficulty of implementing certain features. You made it sound as if drag-and-drop was so easy it could be done with little effort. I presented an algorithm of a reasonable way to implement drag-and-drop on the current device (Kobo Touch). You can see implementation is not trivial. I wanted to see what kind of design you had which made you think it was so simple to implement. That is all.

[BensonBear]

Originally Posted by Xennex1170

It's not so much the discussion as you seem to have no idea of the difficulty of implementing certain features. You made it sound as if drag-and-drop was so easy it could be done with little effort. I presented an algorithm of a reasonable way to implement drag-and-drop on the current device (Kobo Touch). You can see implementation is not trivial. I wanted to see what kind of design you had which made you think it was so simple to implement. That is all.

I already said that in order to know how to implement this on this system, I believe we need to know more details about the hardware and software that we (or at least I) do not know. But, okay, we can speculate a little more even though there is little point to adding such a feature.

You say you "presented an algorithm". But only very vaguely. It does not translate directly into, as you say, "the current device (Kobo Touch)". What is actually done will depend upon the hardware and software. You mention "layers" for example. What are those, exactly? Normally in a sophisticated graphical gui system one has widgets and the widgets are drawn in locations and in layered form. The layers are conceptually encoded into the entire tree structure of widgets as it is created. You would have one widget for the container, and book widgets drawn on top of it. Drag and drop functionality is included in most gui programming systems, so that once you start a drag operation, appropriate messages will be sent to all the widgets when they are exposed and they would take care of redrawing themselves. So your "algorithm" would be distributed amongst the components of the gui. In fact I downloaded and tested this example on my own system, but this is a richer Qt that the Kobo has, so perhaps you are thinking that in a more primitive environment you will manage "layers" more explicitly and directly yourself. Then we still have to know about the environment. The Kobo uses a version of Qt Embedded, but probably a version that doesn't have drag and drop functionality in it. Perhaps the home screen is represented directly as a canvas with all the widgets being hand-rolled lightweight ones. Then, when a move mouse event is detected once a drag is started, yes, one will have to redraw the book in a new position, and redraw whatever was underneath the book before. I don't think that is going to be very difficult, and probably not so slow as to be unusable, although that is a matter of personal opinion of course upon seeing the actual result. But the code is very simple, there will be, I think, three rectangles to blit from a pixmap of the screen as it was: the book, and two rectangles which are uncovered. The cost of drawing them would probably not be so bad. One should only do a redraw if there was a minimal move above a certain distance, otherwise finger stutter might cause some ugliness.

You were concerned enough about there being five book sizes to bring that up. Well, the book has to be the one size by the time it gets down to the bottom, so it is perhaps best to make it that size at the beginning of the drag (or at the drop, if you are dragging the other way). That is not much of an issue as far as I can see.

If it turns out that blitting these three rectangles is too slow and ugly, one could always just use a wire-frame such as the one used in the pdf drag which indicates what part of the entire page is currently being described. Note how, simultaneously with the drag of the entire pdf image, this little rectangle is cleanly updated without any problems. In the old days, this is how windows were dragged and dropped around desktop screens.

I don't see how the code to do all of this is going to be very complicated. Also I doubt it would be so inefficient as to be really ugly (but that is still speculation and a matter of opinion in the end when the result is seen. Maybe it would be too slow for most people). However I believe it would still be a waste of time given all the other things there are that can be done. I think it is pretty silly to be discussing this based on an incidental comment I made (and now, as much time spent on this as I am going to!)

Therefore coming back to reading pdfs: it might make more sense to complain about the requests for "pdf reflow" which suggest it is just one more thing akin to various small requests. This is something that, aside from being ill defined, is likely to be very complicated. Pdf markup does not say what is a header, a footer, a footnote, etc. But to reflow a pdf, one is going to have to detect these things and handle them differently. I have been looking at the code in pdftohtml and it is pretty complex. To assemble a page it finds each little piece of text that is drawn, then assembles them into a structure which it sorts and then tries to coalesce into a linear string of text so that it can extract the text. A lot more complex than dragging a little image. It throws away the position information when it does this linearization so the structure of headers, footers, footnotes, and even margin notes (not that common but for example, the A/B pagination in the Critique of Pure Reason) is thrown away. I think the spatial information could be used to make good guesses at this structure, but this would be pretty complex in general. (Special cases that cover a lot of typical books will not be as hard).

So I do believe I have some idea about "the difficulty of implementing certain features" at least in this case. That is one main reason why I would just like to see pdf reading implemented not by reflow, but by zooming to the maximum in portrait mode and with easily-implemented tap-to-advance-in-document commands. Such a zoom is probably big enough for most people to read. No panning required for typical books.

[Xennex1170]

Originally Posted by BensonBear

...

So I do believe I have some idea about "the difficulty of implementing certain features" at least in this case. That is one main reason why I would just like to see pdf reading implemented not by reflow, but by zooming to the maximum in portrait mode and with easily-implemented tap-to-advance-in-document commands. Such a zoom is probably big enough for most people to read. No panning required for typical books.

Thank you very much. You show a deep understanding of various facets of the problem of drag and drop as well as the workings of how PDFs are defined and implemented. It also seems you know enough about the KT to have access to one if not actually own one. I just thought it might be non-trivial considering that the subject of all this is 'new features in the Kobo Touch' and there is no example currently of drag and drop of any type of image over another in the current or previous firmware. Didn't mean to make it an broad statement over generic/unknown HW/SW.

I like your idea of tapping to advance. May I suggest that it be taken one step further and allow tap to jump up to 1 screen in that direction (up, down, left, right). Also allow a page forward if already at the bottom right and a right|down tap is registered. Similarly a page back if already at the top left and a left|down tap is registered. This would help alleviate use of drag-drop if the text in the PDF was too small to fit width-wise even in landscape mode and had to be zoomed higher.

[BensonBear]

Originally Posted by Xennex1170

Thank you very much. You show a deep understanding of various facets of the problem of drag and drop as well as the workings of how PDFs are defined and implemented. It also seems you know enough about the KT to have access to one if not actually own one. I just thought it might be non-trivial considering that the subject of all this is 'new features in the Kobo Touch' and there is no example currently of drag and drop of any type of image over another in the current or previous firmware. Didn't mean to make it an broad statement over generic/unknown HW/SW.

Yes, I own one, as some of my other posts should indicate. But I have very little understanding of the insides of pdfs unfortunately. One can figure out the basics for typical files by looking at the code and printing out intermediate data structures. Enough to hopefully get some better pdf conversion at some point using heuristics.

Regarding the complexity of the dragging code, pasted below is a self contained qt program that runs on my desktop and should also run on the Kobo if one had a cross-compiler working for it, and stuffed it into nickel, most easily by using the tweaks plugin already existing. It took only about an hour to adapt from some example code, most of which was typing, and it does dragging of book covers. It is extremely simple. (All it does is the drag and screen refresh, though, it does not actually move a book image permanently). In fact it will be noticed that there is no need to do any updating of the screen part that is re-exposed, since qt's canvas widget takes care of that. In fact, there is utterly NOTHING to the moving of the book cover. All the code is just setting things up.

Now this *may* not work in the qt-embedded on the Kobo, and if it doesn't, one will have to revert to some lower level stuff. That is why I said I did not want to speculate about the hardware/software. But pretty sure it will work. Also, if it is too slow to redraw the screen (I doubt that will be the main problem), one can change the drawshape member function to draw a wire-frame. (It has to be changed anyway to draw a cover and not just a solid color -- again, this is not very complicated though).

If I ever get the cross compiler working I can try it on the Kobo. But getting it working is a lot harder than doing the drag and drop. Somehow or other the cross-compiler is still polluted with some local software from my desktop. May have to bug ah- for some hints on this at some point.

I like your idea of tapping to advance. May I suggest that it be taken one step further and allow tap to jump up to 1 screen in that direction (up, down, left, right). Also allow a page forward if already at the bottom right and a right|down tap is registered. Similarly a page back if already at the top left and a left|down tap is registered. This would help alleviate use of drag-drop if the text in the PDF was too small to fit width-wise even in landscape mode and had to be zoomed higher.

Yes, I have posted similar things about this before. To recapitulate:

First: what I believe most people are interested in is pdf books and essays and journal articles. Things that when zoomed in portrait mode so that the entire width of the document is shown, are easy enough to read. Pdfs of course can be of *arbitrary size and shape* and for the unusual ones that are not book sized, the simplest solution I propose is not intended to work. Personally, I absolutely insist that a decent solution allow me to read normal books with NO panning to left and right at all, with typically about a 250% zoom. Others may differ, but that is my bottom line! (and I expect that of many others as well).

Second: given this, we need one command to move forward to the next part of the text currently not visible, and one command to move backward to the previous part of the text not visible. This is *exactly* the same as the epub reader. But it does different things depending upon where one is on a page, as you have pointed out. First I would just get single column reading working, in which it moves down or up in the page if not at the bottom or top, respectively, but otherwise moves to the next or previous page, respectively. This could be made more general with little difficulty for multi-column text.

Third: I would bind these commands to the left and right of the screen. I would use top and bottom of screen to move to the top and bottom of the current page (and perhaps a second tap returns, unless one wants this for some other command). This facilitates an important aspect of pdf that is lacking in epubs: the headers and footers, with footnotes, that a user may often want to consult without having to awkwardly scroll. The middle of the page can be left for a menu. (Or, anything they choose would be okay with the rest of the screen. Also still need to have panning in some cases, for example. But they can do what they want as far as I am concerned if they have the left/right binding, and maybe the top/bottom, which is also easy to add).

There are other things that would be easy to add as well, specifically to help pdf reading. But this is the main thing.

// Very ugly quick test code.  No criticism of style please!
// Build with qmake -project -o books.pro; qmake; make.  

#include <qapplication.h>
#include <qpainter.h>
#include <qcanvas.h>

#define MAX_BOOKS 10
#define BOOK_WIDTH 85
#define BOOK_HEIGHT 140

// hard code a list of books to put in bottom and
// top positions for now.  cover is just a solid color.

struct {
	QColor color;
} g_books[MAX_BOOKS] = 
{
	{Qt::red},
	{Qt::white},
	{Qt::yellow},
	{Qt::green},
	{Qt::blue},
	{Qt::red},
	{Qt::black},
	{Qt::yellow},
	{Qt::green},
	{Qt::blue}
};

// end hard code of sample books


class BookCover : public QCanvasRectangle 
{
public:
	
	BookCover( QCanvas *c ) : QCanvasRectangle( 0, 0, BOOK_WIDTH, BOOK_HEIGHT, c )
	{
		m_width = BOOK_WIDTH;
		m_height = BOOK_HEIGHT;
	}
	
	void drawShape( QPainter &p )
	{
	
		p.drawRect( (int)x(), (int)y(), m_width, m_height );
			
	}
private:
	int m_x;
	int m_y;
	int m_width;
	int m_height;
};



class KoboCanvasView : public QCanvasView
{
public:
	KoboCanvasView( QCanvas *c, QWidget *parent=0, const char *name=0, WFlags f=0 ) : 
		QCanvasView( c, parent, name, f )
	{
		m_draggedBook = 0;
	}
	
protected:
	void contentsMousePressEvent( QMouseEvent *e )
	{
		QCanvasItemList il = canvas()->collisions( e->pos() );
		for( QCanvasItemList::Iterator it=il.begin(); it!=il.end(); ++it ) 
		{
					
			if( (*it)->rtti() != QCanvasText::RTTI )
			{
				
		
				m_selectedBook = (*it);
				
				BookCover *d = new BookCover(canvas());
				
				d->setBrush( Qt::black);
				d->setPen( Qt::black );
				d->setZ(0.0);
				d->show();
	 
				m_xoffset = (int)(e->x() - m_selectedBook->x());
				m_yoffset = (int)(e->y() - m_selectedBook->y());
				
				d->setX(m_xoffset);
				d->setY(m_yoffset);
				d->setZ(1.0);	
				d->setBrush( ((BookCover *) m_selectedBook)->brush());
				((BookCover *) m_selectedBook)->setBrush( Qt::gray );
				
				m_draggedBook = d;
				
				return;
			}
		}
	}
	
	void contentsMouseReleaseEvent( QMouseEvent *e )
	{
		if( m_draggedBook )
		{
			// if book is overlapping with a position
			// and it is not in the group of positions already,
			// move it to that position else do nothing			
			
			((BookCover *) m_selectedBook)->setBrush( ((BookCover *) m_draggedBook)->brush());
			delete m_draggedBook;
			
			canvas()->update();
		}
	}
	
	void contentsMouseMoveEvent( QMouseEvent *e )
	{
		if( m_draggedBook )
		{
			m_draggedBook->setX( e->x() - m_xoffset );
			m_draggedBook->setY( e->y() - m_yoffset );

			canvas()->update();
		}
	}
	
private:
	QCanvasItem *m_draggedBook;
	QCanvasItem *m_selectedBook;
	int m_xoffset, m_yoffset;
};

// standalone main program, easy to remove

#define STANDALONE 1
#ifdef STANDALONE

int main( int argc, char **argv )
{
	QApplication a( argc, argv );
#endif

	// make a canvas, and stick a view
	// on the canvas as the entire subwidget
	// of the current widget
	
	QCanvas *c = new QCanvas( 600, 800 );
	QCanvasView *cv = new KoboCanvasView( c );
	
	// books up top
	
	for(int i = 0 ; i < 5; i++){
		BookCover *b = new BookCover(c);
		b->setX(60 + i * (BOOK_WIDTH+10));
		b->setY(200);
		b->setBrush( g_books[i+5].color);
		b->setPen( Qt::black );
		b->setZ(0.0);
		b->show();
	}
	
	// books in bottom list
	
	for(int i = 0 ; i < 5; i++){
		BookCover *b = new BookCover(c);
		b->setX(40 + i * (BOOK_WIDTH + 20));
		b->setY(800 - BOOK_HEIGHT - 20 );
		b->setBrush( g_books[i].color);
		b->setPen( Qt::black );
		b->setZ(0.0);
		b->show();
	}

#ifdef STANDALONE
	
	c->update();
	cv->show();
	a.setMainWidget( cv );

	return a.exec();
#else
	// code goes here to add this widget into the tweaks widget
	
#endif

}

[immsm]

One thing I would like is a "go to" funtion so you could go to a page you were at when you have to.

[filmo]

Your latest software version with depending only on cover images is sometimes unusable because no title and author below covers. Some really poor unreadable covers out in my world.

Library Books list is ok even with tiny to small to read even best covers because title and author name is next to worthless covers. Really need to fix the home screen by adding same readable title and author below covers.

[The Terminator]

Originally Posted by filmo

Your latest software version with depending only on cover images is sometimes unusable because no title and author below covers. Some really poor unreadable covers out in my world.

Library Books list is ok even with tiny to small to read even best covers because title and author name is next to worthless covers. Really need to fix the home screen by adding same readable title and author below covers.

All firmwares of the Touch are like this, you can use bulk convert in Calibre to add a plain text cover to the book.

[Danger]

Originally Posted by filmo

Your latest software version with depending only on cover images is sometimes unusable because no title and author below covers. Some really poor unreadable covers out in my world.

Library Books list is ok even with tiny to small to read even best covers because title and author name is next to worthless covers. Really need to fix the home screen by adding same readable title and author below covers.

How exactly is this affecting you? I just checked my library and there are 3 views, all three provide me with enough information as to what book is what and by what author. If you are having troubles reading the cover image and are unable to tell what book is what, then perhaps you should change the view. Even with the home screen none of the covers give me any trouble as to which book is which.

If you have crappy covers, you can always use Google, find a good image of your book, and use Sigil to change it in the epub. Or as Terminator suggested use Calibre and generate a generic cover with title & author.

Personally I think the cover view in the KT is quite good.

[Anak]

Add the option to choose your own external font for specific generic font-families: sans-serif, serif, monospace.
Currently you can select only one (overall) font style (family) that applies to all displayed text.

Example
headers, chapter titles ... : font-family: sans-serif;
General text: font-family: serif;

When I select "Adobe Minion Pro" as my preffered external font it will be applied for all text, including chapter titles, text boxes etc.
When tweaking the font-family for headers to "sans-serif" forces KT to display them as "san-serif" but it will be a system default sans-serif font that can not be changed.

[PeterT]

Originally Posted by Danger

How exactly is this affecting you? I just checked my library and there are 3 views, all three provide me with enough information as to what book is what and by what author. If you are having troubles reading the cover image and are unable to tell what book is what, then perhaps you should change the view. Even with the home screen none of the covers give me any trouble as to which book is which.

If you have crappy covers, you can always use Google, find a good image of your book, and use Sigil to change it in the epub. Or as Terminator suggested use Calibre and generate a generic cover with title & author.

Personally I think the cover view in the KT is quite good.

I think he i referring to the view on HIS reader that looks to be a Kobo Wifi and not a Touch!

[Danger]

Originally Posted by PeterT

I think he i referring to the view on HIS reader that looks to be a Kobo Wifi and not a Touch!

Well to put this on topic for the KT... More Reading Life awards... such as "Congradulations you read 5 books while walking!" or "Congradulations you walked _____ meters/Kilometers/miles while reading!" maybe even "Congradulations you read for 20 hours while walking!" Of couse those would be really easy awards for me as I read while walking to work, 20mins a day total.

[filmo]

Subject of this thread is Kobo Touch Future Firmware Feature Request and I pointed out a problem with Kobo Touch Home Page showing only covers without separate Book name and Author. I was not asking how to change covers for books in my Library as I already know how and have done that. I now have owned Kobo readers for over 2 years with 2 Kobo wifi readers and one KT. I have bought 3 new readers from different company over last 4 months that don't have this problem. Kobo can solve their software problems and sell more readers or not. It is their choice not mine.

[tkavan]

I would like to arrange the books in my Library by categories... Biography, Fiction, History, Military, Politics... etc etc

I should be able to either name the categories myself, or pick from a master list the categories that I wish to use.

It would be useful to have sub-categories. History, for example, could have sub-categories such as All, Asia, Europe, North America... etc etc

It would be useful to be able to sort each category differently. For example one might want to sort Biography by title, Fiction by author... etc etc

An individual book title should be able to appear in more than one category.

When I go to the Library I should be presented with a list of categories, each of which would open with a touch to reveal the books in that particular category.

This should not interfere with the ability to place books on the Short-list by "filling in" the heart. (I use this to indicate books I haven't yet read.)

That's it for now! Does Kobo actually pay attention to any of this?

Tom K.

[PeterT]

@filmo: sorry... it is just your user profile shows kobo wifi so I assumed that was what you had....

[Xennex1170]

Originally Posted by filmo

Subject of this thread is Kobo Touch Future Firmware Feature Request and I pointed out a problem with Kobo Touch Home Page showing only covers without separate Book name and Author. I was not asking how to change covers for books in my Library as I already know how and have done that. I now have owned Kobo readers for over 2 years with 2 Kobo wifi readers and one KT. I have bought 3 new readers from different company over last 4 months that don't have this problem. Kobo can solve their software problems and sell more readers or not. It is their choice not mine.

Perhaps a solution would be allowing a long touch on the 'HOME' page book image to show the book's name in a pop-up? Or perhaps putting in a setting that would allow you to default the 'HOME' to your 'Recently Read' library view instead? Maybe a double-click on the physical button so that you don't miss out on using the drop down menu should the above option be allowed.