Yes, Gert perfectly predicted that html is the future. Since, its too easy to adopt, cross platform, fast and powerful.
Let us add little more power to DfM webApp by making UI. We just try to create New User Interface which is posted here.
You are most welcome to create yet another catching UI or moderate the attached UI. Further, you can also put forward your suggestions and comments to improve the UI.
The Best UI will get published as DfM webApp UI. It may also be your's.
Now, The UI's will have similar look in Chrome, Firefox, IE and Mobile Browser. Additionally, we tried to do Metro UI for you. Kindly test and make suggestions on it.
I am amazed how the HMI looks in your proposals !!
Currently there is an adaptation ongoing for the Translation Layer interface (see other postings in the Developers part of the forum). Once I will have adapted the WepApp Translation Layer, I would like to adapt the mini_hmi. Which of your three versions should I use ?
With best greetings,
Gert
Gert,
I glad to receive comment from you. which, encourages me to do more. Let us wait for users to make comments and suggestions in this post. we'll choose the best one according to their choice.
Ok !
For me it is really suprising how you achieved that enormous progress in design with relatively few additions with HTML/CSS.
Regards,
Gert
I updated the mini_hmi with the 'metro' UI and the new WebApp Translation Layer.
I still need to do a lot of testing. Obvious to me are the following problems:
- mini_hmi: the Option Window does not work well; I did not spend any time to fix this, cause I think opening a new window for setting options is very old- fashioned and there should be more modern ways of showing options. For example so that the options slide in on a button press. Any volunteers who like to work on that ?
- WebApp Translation Layer: Chrome shows an "Invalid UTF8 sequence" exception when it encounters a csv file that starts with an UTF-8 BOM; it should also read such files as binary data and not try to interpret its content. This is likely connected to this Chrome bug: https://code.google.com/p/chromium/issues/detail?id=174477 (https://code.google.com/p/chromium/issues/detail?id=174477); I will probably write another bug report. As a workaround we could modify DfM-Creator dictionary generation to throw away any BOM-characters on the dictionary files.
Regards,
Gert
Gert,
We are thinking alike. Because, yesterday itself i've implemented sliding effect for option in mini_hmi. Click on the option to get sliding effect. I'm also working with other themes to provide better UI experiance. In next few days i'll release one by one.
QuoteClick on the option to get sliding effect. I'm also working with other themes to provide better UI experiance.
Wow - that is great !
Meanwhile I did investigate on that "Invalid UTF8 sequence" error thrown by Chrome: this is not a bug in Chrome. Chrome behaves according to the specification:http://encoding.spec.whatwg.org/#decode (http://encoding.spec.whatwg.org/#decode). I personally think that specification is strange because when you explicitly tell XMLHttpRequest with overrideMimeType to use a different encoding (that is what the spec says too), then this is ignored later when the browser does parse the file and detects that there is a BOM. (class HTRInputStream, method readFileJS: http://svn.code.sf.net/p/dictionarymid/code/trunk/WebApp/DictionaryForMIDs_Javascript/Java_for_GWT/src/de/kugihan/dictionaryformids/dataaccess/fileaccess/HTRInputStream.java (http://svn.code.sf.net/p/dictionarymid/code/trunk/WebApp/DictionaryForMIDs_Javascript/Java_for_GWT/src/de/kugihan/dictionaryformids/dataaccess/fileaccess/HTRInputStream.java)).
Chrome previously supported XMLHttpRequest.responseBlob. That was removed in one of the past releases. That means that there is no way to synchronously read a binary file from an non-web worker. Binary reads are necessary for the dictionaryxxx.csv files.
I plan to implement web workers. However I tend to postpone this until a GWT version with better and more stable web worker support is released; also this will be quite some effort, cause Javascript web workers do not allow the same as Java threads do. At the side: the GWT team just fixed a bug that I encountered: http://code.google.com/p/google-web-toolkit/issues/detail?id=7088 (http://code.google.com/p/google-web-toolkit/issues/detail?id=7088).
So I am searching for a workaround for that BOM problem: when putting a dictionary online for the web app, then we could run a script that replaces the BOM bytes with 0-bytes on all dictionaryxxx.csv files. Hmmm, maybe sed could do this.
Ok, next I will write some explanations how to put a dictionary online for the web app. Then we can discuss the way forward.
Best greetings,
Gert
I've added two new UI with Black and White Shades.
Now we have 5 UI's, which are all in beta stage. It need more improvements. improving all the UI's will consume more time.
The improvements would be: adding scroll bar to result table, optionWindow sliding in effect, make header and footer sticky and some minor tweeks with color, font size, style, etc.,
It's time to choose one UI and make improvement on it. Gert, kindly choose one UI and i'll make some improvement to get Final and Better UI.
Stars Soft
Dear Stars Soft,
that all sounds very promising !
I will look at your proposals; question: would it make sense to let the user choose in an option dialogue ? Well, would that be possible with reasonable effort ? Hmmm, guess that would make things too complicated. No, not good idea, let us choose one.
Meanwhile I am hacking a shell script that replaces those BOM-characters with 0-bytes (really a wild hack, but it should be good as a workaround).
Gert
Stars Soft,
I just added your new files for the mini_hmi (.css and jquery) to the manifest. Now the dictionaries should all work offline again. May require a prior cache wipe.
Best regards,
Gert
Stars Soft,
I did run a shell script that replaces the BOM-markers in directoryxxx.csv files with 0-bytes (I think only 3 or 4 dictionaries were affected).
So, that "Invalid UTF8 sequence" should be gone - if it still shows up, please make a posting.
Regards,
Gert
Gert,
Quote from: Gert on 29. October 2013, 16:31:07
question: would it make sense to let the user choose in an option dialogue ? Well, would that be possible with reasonable effort ? Hmmm, guess that would make things too complicated.
It is good idea, with some javascripting it is possible. But, This is not right to implement it. We'll try it in future.
My part of work is pending to release better webApp DfM. Kindly choose one of UI for improvements.
QuoteMy part of work is pending to release better webApp DfM. Kindly choose one of UI for improvements.
Hmmmm, really not easy to have a preference. Well, if I would have to state a preference, I think the metro look might be mine.
Gert
Dear All,
The Metro UI is ready to release with webApp. Hmmm, I tried atmost to provide better and universal look in all browser. I think it got worked.... I'm waiting for your feedback to improve it more.
It has been tested with some browsers and the report is:
1. PC Chrome : Working,
2. PC Firefox : Working,
3. PC IE8 : Working (I don't have IE 9/10 to test it),
4. Android Chrome : Working,
5. Android Firefox : Working,
6. Android Native Browser : Working,
7. Android Opera : Working,
8. Android Dolphin : Working,
9. Android Maxthon : Working,
Best Wishes,
Stars Soft
It is _very_ useful that you could test it on so many browsers !
I do have to make a restriction, though, on IE8: the WebApp Translation layer uses several HTML5 features; IE8 does not support HTML5; I believe also IE9 has some limitations in HTML5 capabilities.
Means Internet Explorer 8 will not run the DictionaryForMIDs WebApp, possibly Internet Explorer 9 neither.
I uploaded a new version of the WebApp Translation layer. That version checks the availability of the needed HTML5 freatures during startup. If something is missing, then this is reported in an alert box.
Best regards,
Gert
I just tested with Internet Explorer 10: even not Internet Explorer 10 does provide sufficient HMTL5-capability ! The WebApp Translation Layer does report this problem during startup. Translations will not work with Internet Explorer 10.
According to the Microsoft documentation the Internet Explorer version 11 will work.
Regards,
Gert
Good news: thanks to the support of V.P. Guru, the OptionWindow is now operable ! :)
I just updated the mini_hmi on the web server. It is now possible to select the translation direction on the mini_hmi user interface.
One restriction: only 2 language dictionaries are currently supported by the OptionWindow.
Thanks to V.P. Guru !
Gert
Yeah....!!! DfM webApp is working smoother and faster....
Now, DfM is available in all platforms.
I guess, Gert will expand DfM webApp to support more than 2 languages.
QuoteI guess, Gert will expand DfM webApp to support more than 2 languages.
Ha, I already spent much time on the OptionWindow, cause I am really not familiar with development of HTML/Javascript ... and I have such a long todo list with other pressing items 8)
Besides, the DictionaryForMIDs WebApp is also even running on the Wii U, it looks very nice there too ;D
Regards,
Gert