And that makes it easier to handle future updates.
I agree, if something happens you would know if it was my code and you could easily contact me to fix them.
If you would like to enter your name and copyright information where relevant, please make pull requests where needed.
Alright, I will do that later, thank you.
Okay, from @warpok's 7 points I've only been able to solve the 1st, 2nd, 3rd and 7th point, I will be working on the unification and then go back here to see what I can help with the rest. Here is the new files (header.js and stylesheet.css) already in their respective folders: bibledit-visual-improvement-bugfix-20th-march-2021.zip
The old vertical slider might be OK for most books and chapters. The exception would be something like Psalms and chapter 119.
I will see what I can do with that, for now I've only made it to be displayed the same way as the book selector.
Also, I saw that you added the active CSS class on the bible book selector through C++ @teusbenschop in /changes/changes.cpp. I don't know how to do that yet to the workspace selector as @warpok 2nd point, so I added some workarounds with Javascript in the header.js file. Basically it looks into the full path of the page, take the two last characters, pick the numbers inside the chosen characters, then loop over the span child elements of the workspace picker (the one with the fadeout class) and add the active CSS class to the one with the index equal to the numbers picked before.
If you want to add the feature in C++ feel free to do that and remove the last block of code in the header.js file. Or you can point me to where I might do that and I will try to write it, I think it's configured in /changes/changes.cpp too?
Thank you!
Edit: Now the 1st, 2nd, 3rd, 5th, and 7th point are fixed. I've included them in a pull request, #517.
What WONDERFUL progress! Way to go Aranggi and Teus.
One thing doesn't work: I have our Notes set to show the color according to the Status. But the Notes are all showing one color again. Bottom setting:
I suspect this will be remedied when the stylesheet is updated correction that you were talking about.
Also, the first setting on the screenshot above is the 4 second setting for collapsing the extra menu choices. At first I thought that this was not working. It is working, but takes between 7-9 seconds on my old laptop.
As for hot keys, I just want to say how happy I am that the Ctrl-G still works to quickly move to different places in Bibledit.
That is the ONLY choice if working on Psalms:
The same is true when there are more than 31 verses.
There was an enthusiastic message in our team WA group from Budi sending emoticon thanks to you Teus!
Thanks to you too, Aranggi.
Glad to see how nice and how well it now looks, it's going well the way it's going now.
If the chapter selector could fold over multiple lines, then it would be easier to see all the chapters available. And the same for the verses. Then all the chapters can be selected, and all the verses, if there's many chapters or many verses.
The team's reaction was only about one menu line not disappearing. One was a Chromebook user. From what I saw, sometimes the extra menu does not collapse even after 10 seconds. But for me, it has been collapsing, just taking extra time.
I like the idea of the chapter and verse selectors folding over several lines if necessary. Most of the time, on my desktop, it won't need to fold.
Another thing I notice is that the colors for the OT and NT are not different, as they were in the mock up.
I received two emails from members delighted by the changes in the interface.
At this point in the Guest site (or admin for that) The pretty tabs switch to the old colors before going back to the proper colors. The first tab in the old colors is canary yellow, so it makes quite a contrast.
Aranggi said that 1 and 2 had been done. But the Old Testament and New Testament books in the book picker are still one color.
2. The active tab is not showing a different color when activated, like an outline or a switch of color for the tab title.
At this point in the Guest site (or admin for that) The pretty tabs switch to the old colors before going back to the proper colors. The first tab in the old colors is canary yellow, so it makes quite a contrast.
Aranggi said that 1 and 2 had been done. But the Old Testament and New Testament books in the book picker are still one color.
2. The active tab is not showing a different color when activated, like an outline or a switch of color for the tab title.
Yes @warpok I saw that just now, that was unexpected. I will see what's wrong right away!
Not is Basic mode, but an issue with tabs: On my Tablet, the tabs refuse to collapse, no matter how long I wait.
On my computer, I notice that the Tabs stay non-collapsed as long as the cursor is anywhere up in the menu area.
Note that in the cloud using the Chrome browser on Android, not only does the workspace menu stay on the screen, but it did not update with bolding the 3B workspace. The active workspace in this screenshot is not the 3bagian one, but the 3B one.
When saving a Note in the Notes pane, before the right menu comes back to that pane, a ghost menu appears that it W T C …
= Workspace Translate Cari …
This is the program trying to write the main menu first in the Notes pane, but then the real menu appears: Notes [Select] [update] …
Aranggi, saya mengusul mengubah favicon untuk Bibledit. Saya senang logo Bibledit yang baru kalau terlihat besar. Kalau kecil seperti favicon, kelihatannya seperti ibu gemuk dengan dua buah dada besar. ;-)
Hapuskan dua garis di bawah buku, dan membesar sehingga bentuk Alkitab bisa terlihat. Mungkin tidak perlu kedua sisi buku kelihatan. Bisa halaman di kiri atau di kanan.
Hello @teusbenschop and @warpok! I've fixed a few bugs and added a pull request at #528.
It was four things:
The switching tabs color while loading
The Bible book picker background color not showing
The active workspace not being distinguished from the inactive ones
Workspace tabs that doesn't fadeout and not shown full in small devices
The third fix @teusbenschop might want to look at. I was figuring out how I can replicate the active class addition to books/chapter/verse picker to the workspace tabs. And what I came up is to add a small code that inserts the class into the workspace HTML generator as you can see in the pull request. I don't think it will mess with other parts of the generator as it is just adding into the premade HTML, but maybe there is a better place to put it. You decide brother, @teusbenschop.
The fourth one is just rolling back into the original function, I haven't figured out how to make the delay stop while the user is choosing the workspace.
Edit: I missed a whitespace on one of the bugfixes, sorry! Added a new pull request at #529.
4 seems fixed. The extra tabs very nicely scroll away on my tablet. Beautiful.
There are colors for the OT and NT. (Rather garish colors, unfortunately.) I suggest that you make the colors for the different kitab like the darkest blue tab and the darkest red tab, so they will match better.
3 is still not finished. But that is very minor.
is fixed.
Issue 5: The main menu tries to draw itself in the Workspace Notes pane/window in Advanced Mode. I sent Aranggi a video of this. (The Guest Users won't see that, because they only have basic mode. It doesn't do that in Basic Mode.)
Teus, please give the new version of the tabs to us in the TSI port.
Teus, one of the basic mode tabs was still not translated. (The translate button.) It has been translated now, and I also translated Basic mode.
Please re-import the new Indonesian translation.
And I can't seem to access the advanced mode in port 8083, can you elevate my role? The username that I registered with was "a_toar". Only then I can help with the third and fifth issue. Thank you!
Teus, one of the basic mode tabs was still not translated. (The translate button.) It has been translated now, and I also translated Basic mode.
Please re-import the new Indonesian translation.
The updated Indonesian translation was imported, I could see the three new translations. It's being installed to the 8082 port now.
About the fifth issue, it's not only on the notes workspace iframe but in every workspace iframes. I think it's because the same HTML code that is used to generate the main screen/display is used to generate the workspace iframes. The second part (from around 40th second) is for @teusbenschop to see about this issue.
I see that what @teusbenschop did was to create a condition to display or not to display the topbar. But that condition is only applied after the whole HTML is generated. Hence the momentarily blink of the topbar.
So if we were to make the topbar to not even be generated, what we would need to do is to separate the HTML generator for the main screen/display with the one for the workspace iframes, is that right @teusbenschop?
About the fifth issue, it's not only on the notes workspace iframe but in every workspace iframes. I think it's because the same HTML code that is used to generate the main screen/display is used to generate the workspace iframes. The second part (from around 40th second) is for @teusbenschop to see about this issue.
I see that what @teusbenschop did was to create a condition to display or not to display the topbar. But that condition is only applied after the whole HTML is generated. Hence the momentarily blink of the topbar.
So if we were to make the topbar to not even be generated, what we would need to do is to separate the HTML generator for the main screen/display with the one for the workspace iframes, is that right @teusbenschop?
What you point out as the cause of the short blink of the topper looks to be the correct diagnosis.
Yes, I made it to hide the topbar when the page was inside an iframe, and if not in an iframe, the topbar remains as it is, that is, it remains visible.
The issue I ran into initially, while writing this, was that C++ does not know whether the page that is should generate is called from an individual page, or from the same page running from the iframe. And even today I won't know of a simple way to let C++ know about that.
The issue does not display in the original stylesheet, so is the updated stylesheet.css different that is now shows the blinking?
The issue I ran into initially, while writing this, was that C++ does not know whether the page that is should generate is called from an individual page, or from the same page running from the iframe. And even today I won't know of a simple way to let C++ know about that.
Reading the code again it seems that the condition inside the displayTopbar() function is never passed. I think that query that you built is not being read because request->query.count ("topbar") would only read the actual URL and not the URL that is being generated with filter_url_build_http_query function that you made. This is a short video of how I come into that conclusion.
If there is no solution yet then we can post it as an issue for the future.
Edit: The screenrecorder doesn't detect the browser window that I pulled up, this is what I was pointing at in the middle of the video:
I have tried too to get the blinking visible, but the internet connection is fast enough here so the blinking, although it's there, it won't be visible to the naked eye. In the video that you recorded, the blinking is clearly visible from your end.
Question: Do you also see the blinking at http://bibledit.org:8090 ? That website uses the current styling and CSS. Does it show the blinking too from your end?
Reading the code again it seems that the condition inside the displayTopbar() function is never passed. I think that query that you built is not being read because request->query.count ("topbar") would only read the actual URL and not the URL that is being generated with filter_url_build_http_query function that you made.
The topbar is really being read, here's a screenshot of that.
Question: Do you also see the blinking at http://bibledit.org:8090 ? That website uses the current styling and CSS. Does it show the blinking too from your end?
Sadly yes, it still shows, sometimes just a blink but other times it stays on the screen for a good few seconds. Here is a screen recording.
The issue is that the ?topbar=0 is generated upon loading the . But when starting to switch pages inside that , it is no longer being generated by the C++ code. The still has the "topbar=0", but the pages switch their own URL, so C++ gets the new URL every time a link is clicked. And those are always without the "topbar=0".
Ah, thank you, I understand better now. The problem is not about the value not being read but the page that's loading is not being loaded with the built query.
I thought of another thing that might work, but I don't know how to write it yet. How about writing an AJAX request in place of the current $ ("#topbar").empty (); function you wrote, that will send a request to the current workspace generator to add ?topbar=0 into these functions in the C++ HTML generators:
If not that, could we set a specific value into the style tag of the header? Maybe you already know, but there is a specific value for the display property in CSS, that's called none. It will make the designated element not rendered into the page's layout, even though it's still there. That might make the topbar not to blink because the styling is set before the topbar is rendered as the generator is generating the header first before the workspace.
I thought of another thing that might work, but I don't know how to write it yet. How about writing an AJAX request in place of the current $ ("#topbar").empty (); function you wrote, that will send a request to the current workspace generator to add ?topbar=0 into these functions in the C++ HTML generators:
That could work in the situation that all pages are either in the workspace, or are either not in the workspace. However you can certainly try it out to see if that will kind of help in some ways.
If not that, could we set a specific value into the style tag of the header? Maybe you already know, but there is a specific value for the display property in CSS, that's called none. It will make the designated element not rendered into the page's layout, even though it's still there. That might make the topbar not to blink because the styling is set before the topbar is rendered as the generator is generating the header first before the workspace.
I think that would work too, probably a good idea, you can certainly try that out.
A third method could be if the header.js, if it sees the ?topbar=0 in the query, that it updates all href values on the page to also include the ?topbar=0. That way, clicking any link on the page within the will always add the ?topbar=0.
So yes, there's more than one way of resolving it, brother!
And here is the pull request containing the new code #544.
As I've written in the pull request, it is solved for now. I have yet to know every kind of page that could be generated in Bibledit, so I've applied the fix only to the ones that I know (such as the items in the default workspaces). In the future if the same bug reappear, the same fix can be applied easily.
@teusbenschop your solution was the one that worked! One thing is that I forgot to delete part of the code that didn't work, it's the querySelectorAll for input and button elements and the respective forEach function applied to it. You can just erase these codes. Another thing, the change in notes/quill.js is simply adding the topbar=0 query into the page that those AJAX requests will be sent.
Hello thank you for resolving the issue with the flashing topbar.
The screen recording looks good in a Workspace.
Have you tried also how the pages operate in stand-alone mode? I am asking because in stand-alone mode the topbar should be there. So I just wonder if that works well in stand-alone mode.
Good luck fixing it @aranggitoar . One way of fixing it could be to check if the "topbar" is passed in the page URL, and then if it's passed, only then to add it to the hrefs on the page. I'm sure you'll find a way to fix it.
Hello @teusbenschop, now it's solved for real! Thank you, what you were suggesting is the method that was implemented already. What that didn't solve was actions on Cancel and Create buttons such as on the notes workspace. Because they don't have an href element and their capability to redirect the user is from AJAX in notes/quill.js.
Do you know of other pages that would behave similarly? I'd be glad to add this fix there as well, so the whole app will be clean.
The problem was that I hardcoded the query in notes/quill.js. Now the query will be added in the window.location.assign function only when the current window is not the main one, using an if statement with window.self !== window.top condition. I've updated my forked repo and added the new fix here: #544.
Hello @teusbenschop, now it's solved for real! Thank you, what you were suggesting is the method that was implemented already. What that didn't solve was actions on Cancel and Create buttons such as on the notes workspace. Because they don't have an href element and their capability to redirect the user is from AJAX in notes/quill.js.
Ah, great it's resolved now, glad to see this.
Do you know of other pages that would behave similarly? I'd be glad to add this fix there as well, so the whole app will be clean.
Out of the top of my head I won't know of such, but that does not mean they are not there, it just means I cannot recall such redirects via AJAX immediately. Best might be to check on those.
It looks good now, really, nice to see the app behave so nicely.
There's still one issue that I can see in the video. It is about creating a new note. After creating a new note, the user is supposed to be taken to the list of notes. That is the standard and intended behaviour. But in the video after the user creates a new note, the user is taken to the Home Screen of the app.
The problem was that I hardcoded the query in notes/quill.js. Now the query will be added in the window.location.assign function only when the current window is not the main one, using an if statement with window.self !== window.top condition. I've updated my forked repo and added the new fix here: #544.
Thanks for the updated pull request, I'll merge it and install it to the various Bibledit Cloud instances.
There's still one issue that I can see in the video. It is about creating a new note. After creating a new note, the user is supposed to be taken to the list of notes. That is the standard and intended behaviour. But in the video after the user creates a new note, the user is taken to the Home Screen of the app.
About the small hiccup. That was related to my fix, sorry!
It's because I added a new variable and assigned an empty array into it. It should've been an array with empty string instead, so it wouldn't mess with the default function. Now I've added the empty strings, and it's working fine. Here's a screen recording regarding the fix. And I've added a pull request here #549.
Out of the top of my head I won't know of such, but that does not mean they are not there, it just means I cannot recall such redirects via AJAX immediately. Best might be to check on those.
Alright! Yeah might be best to think about it, please tell me if you found some. I will look out for them as well in the coming days.
Here is a mockup/prototype of the 5 tabs CSS element:
https://aranggitoar.github.io/navbarmockup.github.io/
It was created by @aranggitoar