Web browser for DR1000S

[pthwaite]

Dixon,
not at all a stupid question,however, yes I restarted.
Mackx
Thanks, I did change the DR file when connected to the PC. Maybe I'll whip out the SD card and try it that way.

It's no great hardship to just open the file from the Midori menu however, I'm just surprised it doesn't work for me as It appears to do for others.

In fact I may delete the file and get the irex to create another & try again.

2 options to have a go with now

[omro]

oops mispost, sorry

[robvh]

[QUOTE=dixon;617614]Hi,

Originally Posted by dixon

Hi,

here is a new version of the Midori browser for firmware v1.7 (MD5: 3810a2c6ef4a0449ab15867256b88db9). List of changes:

• Midori browser upgraded to version 0.1.10
• MIME database added (i.e. browser can open images now)
• Full screen mode is allowed
• File open dialog changed (thanks Mackx for explaining)

To robvh:

1. I have not noticed empty scrollbars on small pages. Maybe it was fixed in 0.1.10.
2. Links to pictures should work now.
3. The file open dialog should be better now.
4. I can't reproduce. I just go to Edit -> Preferences and after browser restart I can see configuration changes I made.

Hi Dixon,

Thank you very much for your improvements. Linking to images works fine now and also the empty scrollbar space problem has been solved, which means that the images are using the full available space.

The dialog box is much better, although I would prefer to see many more files at once rather then using the scrollbar. Specially because it seems that the order of files is not related to an alpha-numeric order but in my vision completely random.
This makes searching for the correct file with the scrollbar a difficult and time consuming task and many times I can't even find the correct file.
So my first qeustion is: is it possible to get the files in an alpha-numeric order presented?

Going to preferences in midori is indeed working fine but that was not the problem I tried to explain. I did make the changes in the config file on my PC and did expect to see effect from that. In fact I tried to get rid of the scrollbars but since this issue is beïng solved this is not important anymore. Now here I noticed strange effects. First of all changes do really take effect if _midori/config/config is beïng changed by editting the file. However once midori is beïng used the date of the config file is beïng changed and set back to its original date. So the file stays changed but is rewritten (since looking into the preferences without changing anything will already rewrite the file) but the date writing date is beïng set back to the date of the directory config. This did cause confusions in what really happens. Knowing this did solve at least my question.
I also saw in the config file that not all available parameters can be editted in the preferences.

Since I now can really use the device as I like to do, having one or two index html pages with hundreds of links pointing to the different image files, I run into many more unexpected and also unreliable problems, which will stop me using midori in a live situation (on stage).

First of all I try always to switch to the nice new full-screen mode. This causes to get rid of the upper toolbar, the in version 1.7 (DR1000) introduced side bars and the bottom bar from the DR1000S creating the maximum available space for the image and still having one toolbar at the top which can contain all the necessary tools I need. This is very nice. The first extra button I added was the "refresh button" and why will become clear below.

The most irritating thing is that as soon as you point with the stylus anywhere in the screen, the image is enlarged to its original size. One feature stated in the config file is: "auto-shrink-images=true".
This causes a lot of trouble. Touching the screen by accident or multiple times happens many times. Especially if you choose a link and no direct reaction follows, you will touch it a second time and then the image opens in the enlarged original size. I really get mad.
My second question is can I switch of this property that it switches back to its original size touching the screen? I will never intend to use it anyway.
So it should always in the "auto-shrink-images=true" mode but without the toggling mode between "original" and "fitting screen" size due to screen touching. If I resized all my images to fit the screen up front and set the auto-shrink to false the problem could be solved of course.

Apart from this more things go wrong if the default "true" mode for auto-shrink stays implemented.
If you choose for full screen at the moment an image is beïng present, the top toolbar, which should vanish stays visible and the second toolbar vanishes instead of coming up on top. At least this is what you see!! However if you want to use the functions of what you "see" you will notice that the second toolbar is actually present. So it acts on the invisible buttons of the second toolbar. Since I know that I putted a rehresh button in the left corner so I just refresh the screen by touching the left corner and then the correct toolbar shows up.
The problem is caused by the auto-shrink action if the image goes to full screen size. If the auto-shrink is true it takes two steps to refresh the screen.
It seems that the first step which tries to put the correct toolbar on top is beïng interrupted by the resizing of the picture and then still the first toolbar (File Edit ....) stays visible as picture on top and is not replaced. Then the resized image fills in and the wrong toolbar stays.

Now when I switch back to the index page and pick another link, also many times (50% or much more) it is not the new image which appears but the index page itself is refreshed one or sometimes two times and then it stops. That because the linked image is not ready yet to show up. If I then refresh the image the actual present image shows up. In rare cases linking finishes directly the first time but it still takes two refresh steps. A first step where the already present index page is beïng refreshed and a second step that the actual choosen image from the link shows up.
If the auto-shrink is NOT in the "true mode" but "false mode" the image will show up always faster mostly (not always) in just one refresh action instead of two, so the correct image shows up directly. But if it still takes two steps it never hangs during the first step.

However in the "true mode" when it stops and it refreshes only the index page one tends to touch the link a second time and then the image shows up immediatly but in the original size (too large). This because one is thinking to touch the link a second time but in reallity one is touching the image which is invisible present behind the index file (like with the wrong visible toolbar). So it thinks that it had to toggle to the original size.

A long story, but I hope I made this "bug" clear.

robvh

[robvh]

Hi,

I'm trying to use scribble in the midori webbrowser. It seems that there is no tab "Tools" with icon "writing" available in the SDR1000S "menu" like with pdf files. So it seems I can't add scribbles to these pages. Is this normal?
If so how can I implement this function?

robvh

[pthwaite]

As far as I'm aware, you can only scribble in pdf documents and their templates. Other applications would have to be written to accept scribbles, such as xournal and one or 2 others. For instance you can't scribble in a mobi book.

[Mackx]

Originally Posted by robvh

I'm trying to use scribble in the midori webbrowser. It seems that there is no tab "Tools" with icon "writing" available in the SDR1000S "menu" like with pdf files. So it seems I can't add scribbles to these pages. Is this normal?
If so how can I implement this function?

Scribble functionality is part of an application, it is not a feature of the 'DR as is'. For pdf, text and images the UDS-application from iRex is used. This one supports scribbles. Another application that supports scribbling is Xournal, but that is all build into the application, with only low level support from the firmware. What you want is some kind of merge between midori and xournal. This will be very difficult, since html is rendered differently depending on the size of the window (so were to put the scribbles when viewing the html-file on the PC?)

[robvh]

Originally Posted by Mackx

What you want is some kind of merge between midori and xournal. This will be very difficult, since html is rendered differently depending on the size of the window (so were to put the scribbles when viewing the html-file on the PC?)

Hi Mackx,

Thanks for this clear explanation. I use normally pdf to add scribbles to my music sheets which are images. However midori is much faster in choosing arbitrary links to images from an index. All images have the same fixed format. So the format is constant and once scribbles were related to an image on my SD1000S I'm not interested in other window-sizes nor how it looks at another device (PC). Does that open any perspectives?

I'm not familiar with xournal, so that merging remark didn't ring bells. I tried to play with it, didn't understand the whole tool. And scribbling did not have any feed back. The scribbles showed up afterwards when choosing another function. Must be a bug.

Direct choosing PNG images from a SDR1000 directory is an image function enabling scribbling in the popup menu. Direct choosing HTML let you show the menu toolbox as well, but with a blended writing icon. So there you cannot scribble. In midori I link directly to PNG images (not embedded in a html page), so somehow I get an impression it may be possible to implement an scribbling function by just enabling the function somewhere?

robvh

[Mackx]

Originally Posted by robvh

Thanks for this clear explanation. I use normally pdf to add scribbles to my music sheets which are images. However midori is much faster in choosing arbitrary links to images from an index. All images have the same fixed format. So the format is constant and once scribbles were related to an image on my SD1000S I'm not interested in other window-sizes nor how it looks at another device (PC). Does that open any perspectives?

I have not looked into midori myself, so I can not give an answer on that. It needs to be build into the application!

Originally Posted by robvh

I'm not familiar with xournal, so that merging remark didn't ring bells. I tried to play with it, didn't understand the whole tool. And scribbling did not have any feed back. The scribbles showed up afterwards when choosing another function. Must be a bug.

Making scribbles with Xournal is not as stable as with the native app, therefor default the 'slow-and-safe' mode for scribbles is enabled, which indeed gives very late feedback. The 'fast-and might-crash' mode can be enabled via Options->Experimental Update.

Originally Posted by robvh

Direct choosing PNG images from a SDR1000 directory is an image function enabling scribbling in the popup menu. Direct choosing HTML let you show the menu toolbox as well, but with a blended writing icon. So there you cannot scribble. In midori I link directly to PNG images (not embedded in a html page), so somehow I get an impression it may be possible to implement an scribbling function by just enabling the function somewhere?

Unfortunately midoru renders the images and not the UDS-application of iRex. I do not think it will be easy to start the images in UDS via midori.. and if it will not be very fast ...

No real help yet for your 'problem', I hope it does not effect you music playing capabilities

[robvh]

Originally Posted by Mackx

Unfortunately midoru renders the images and not the UDS-application of iRex. I do not think it will be easy to start the images in UDS via midori.. and if it will not be very fast ...

No real help yet for your 'problem', I hope it does not effect you music playing capabilities

If using pdf I can just keep up with the other musicians using old fashioned books, as long as I'm not choosing the wrong piece of music by mistake...
Hope that somebody try's to implement scribble (a fast one....) in midori or that pdf renders faster. Faster pdf must be possible too because I think pdf renders more pages at the same time to make live easier the next time for the next page. This is not an appropriate manner for me since I choose random pages...so a fast "one arbritrary page" render will help a lot.
Anyhow thanks for your clear answers.

[Mackx]

Originally Posted by dixon

I also promised to post the build instructions. So here they are.

I finally found some time to follow the instructions, they indeed work as you described. Thanks very much I learned some extra 'porting tricks'.

My goal was to add some code to show midori in the Task Manager and the Task Bar, but for some reason that is failing until now.

[dixon]

Originally Posted by Mackx

I finally found some time to follow the instructions, they indeed work as you described. Thanks very much I learned some extra 'porting tricks'.

My goal was to add some code to show midori in the Task Manager and the Task Bar, but for some reason that is failing until now.

You are welcome. It's a busy time for me but I follow posts in this thread and I'm going to implement requested fixes/enhancements when I will have a chance. Nevertheless if you have some specific questions feel free to post it here or send me PM. Two minds are better than one

[badbob001]

Does this have anything to do with the webkit-based browser that IREX is working on? They contracted with Collabora to develop one and says the code from the project is available on the irex site. Presentation slides are interesting. Mentions rendering a flash frame and viewing wide pages with just page up/down.
http://www.collabora.co.uk/services/case-studies/irex

In a recent DR800 video, access to the Barnes and Noble store is nothing more than a web browser view to BN's ebook mobile site. It would make sense for that browser to be related to their existing webkit effort.

Image from the programmer's site. Not sure if the browser really looks like that:


Little more info here, like why the browser will not be ported to the iliad:
http://blog.barisione.org/2009-02/we...gital-readers/

[Mackx]

Originally Posted by badbob001

Does this have anything to do with the webkit-based browser that IREX is working on? They contracted with Collabora to develop one and says the code from the project is available on the irex site. Presentation slides are interesting. Mentions rendering a flash frame and viewing wide pages with just page up/down.

For some reason they have not released this code yet. I think they wanted to incorporate it into the DR1000SW, but that machine did not make it yet. Maybe they will (re)use it for the DR800.

Originally Posted by badbob001

Image from the programmer's site. Not sure if the browser really looks like that:

Well it looks like a real native DR app.

Dixon ported an existing browser, that also uses WebKit, to the DR. So it is a different approach then where you refer to, which seemed to have build a new browser around webkit. It would be nice to get a hand on that code...

[ericshliao]

Originally Posted by badbob001

Little more info here, like why the browser will not be ported to the iliad:
http://blog.barisione.org/2009-02/we...gital-readers/[/url]

It's true. Officially, iLiad has no generic way of controlling screen refresh as DR1000S does. That means porting every application to iLiad requires adding code to control screen refresh. It's not an easy task.
Fortunately, brilliant people have developed one for iLiad users. Now,it's not a problem to port WebKitGTK and Midori to iLiad. The better thing is, we can port application more than GTK+ based, such as QT, wxWiget, FLTK to iLiad. If people want to port applications other than GTK+ based to DR1000S, he has to add screen control code manually.