Suggestion in Project 1: Liblouis table editor

[Riya Jain]

Hi, I actually wanted to suggest amends to the first project `Liblouis table editor` after I had a conversation with @Nalin. I went through the idea and even implemented a prototype with the recommended technologies (Python with PyQt5). While doing this, a suggestion came up in my mind so I thought of sharing it with you all.

So, my suggestion is, instead of using PyQt5 for developing the table editor. I’d recommend a web based editor written in some javascript framework like React, Vue, Svelte or something along those lines (React would be a personal recommendation due to the robustness it offers).
The advantages of doing this would be:

• Easily accessible to anyone via the web.

• Easy to implement Accepted Web Standards for accessibility (which is a requirement for the project)

• PyQt5 would have the advantage of an installable binary but a similar behavior would be achievable with ElectronJs which is a framework which allows compiling web applications targeting platforms like macOS, Windows, and Linux. (Needing an active internet connection would have been a disadvantage of the web based approach but it can be tackled with help of electron)

• Easier to provide future updates (An installable made via PyQt5 would need to be manually updated) whereas a web based application updates whenever someone revisits the url with an active internet connection.

• Easier to maintain, There are just simply more volunteers and developers in the web technologies ecosystem.

Do let me know your thoughts, if you have any recommendations for the web application approach. I myself am interested in working on this project and would love your feedback. I myself am versed in such web technologies and would love to see this project to its end.

[Pratyush Kumar Chouhan]

 Hi Riya, While your suggestion of using a web-based editor written in JavaScript frameworks like React, Vue, or Svelte has its merits, there are several reasons why the project might have opted for PyQt5 instead:

• Mentors and community contributors may have more experience with Python and PyQt5, leading to faster development.

• PyQt5 applications typically offer good performance, especially for desktop tasks like table editing.

• PyQt5 applications can run offline without additional dependencies, crucial for users without constant internet access.

• PyQt5 executables have smaller file sizes and are easier to distribute across platforms compared to web-based apps packaged with Electron.

• Some users prefer desktop applications for performance and offline access, allowing the project to cater to a broader range of preferences.

In summary, while a web-based approach has its advantages, such as easier accessibility and updates, the decision to use PyQt5 for the table editor project might have been based on factors like existing expertise, performance, offline functionality, native integration, deployment flexibility, security, and user preferences.

[Samuel Thibault]

Mmm, interesting point.

What I have seen in the liblouis project mailing list is that it's quite often non-technical people who would like to contribute text tables, so lowering the entry barrier as much as possible would probably be very useful, up to the point that the liblouis documentation could point to the editor on the web and tell to just submit what it produced. Providing an electron version so it can be also used offline can be indeed very important for various people.

Concerning the accessibility of web / electron applications, it depends a *lot* on how it is implemented. I guess the gsoc project can make a good job at producing something very accessible.

Concerning the speed, braille table editing shouldn't be very involved, so I'm not really afraid of possible difficulties there.

There may be some questions though: for instance, where would this be hosted long-term-wise? Would the liblouis project want to host it somehow? This would need to be discussed there.

Also, the question is the maintenance of the project long-term-wise. We need to have something that maintainers are keen on maitaining.

[Nalin]

Hello, 

Here are my thoughts:

1. Liblouis is used by many projects with a variety of licenses, including proprietary ones, so an offline version is inevitable.

2. In some cases, Liblouis table editing becomes tedious, and editors tend to rely more on native applications than web applications.

3. How we manage different versions of Liblouis? To my knowledge, projects that use Liblouis all use different versions, not necessarily the latest. 

So, we have to provide multiple versions of Liblouis inside the server for testing the tables, and some tables may depend on many other tables.

4 What about API availability for building the web version?

Zendalona can also provide hosting facilities if we opt for the web version.

Regards,
Nalin
Mentor, Zendalona GSoC 24.

[Benson Muite]

Qt6 has been released and will also work on mobile phones (Android), as
does Qt5. Qt applications typically also require less hardware resources
than electron applications.

QtQuick offers a development experience that should be friendly for
someone with experience developing web applications:
https://doc.qt.io/qt-6/qtquick-index.html

An example application using QtQuick is GCompris:
https://gcompris.net

If using Qt, care is needed in making sure the application is
accessible, web accessibility standards seem more thoroughly developed.

Electron applications tend to be more difficult to package for linux
distributions.

> *

>
> Mentors and community contributors may have more experience
> with Python and PyQt5, leading to faster development.
>

> *

>
> PyQt5 applications typically offer good performance,
> especially for desktop tasks like table editing.
>

> *

>
> PyQt5 applications can run offline without additional
> dependencies, crucial for users without constant internet
> access.
>

> *

>
> PyQt5 executables have smaller file sizes and are easier to
> distribute across platforms compared to web-based apps
> packaged with Electron.
>

> *

>
> Some users prefer desktop applications for performance and
> offline access, allowing the project to cater to a broader
> range of preferences.
>
> In summary, while a web-based approach has its advantages, such
> as easier accessibility and updates, the decision to use PyQt5
> for the table editor project might have been based on factors
> like existing expertise, performance, offline functionality,
> native integration, deployment flexibility, security, and user
> preferences.
>
>
>
> On Sunday, March 17, 2024 at 7:56:23 PM UTC+5:30
> riya1j...@gmail.com wrote:
>
> Hi, I actually wanted to suggest amends to the first project
> `Liblouis table editor` after I had a conversation with
> @Nalin. I went through the idea and even implemented a
> prototype with the recommended technologies (Python with
> PyQt5). While doing this, a suggestion came up in my mind so
> I thought of sharing it with you all.
>
>
> So, my suggestion is, instead of using PyQt5 for developing
> the table editor. I’d recommend a web based editor written
> in some javascript framework like React, Vue, Svelte or
> something along those lines (React would be a personal
> recommendation due to the robustness it offers).
> The advantages of doing this would be:
>

> *

>
> Easily accessible to anyone via the web.
>

> *

>
> Easy to implement Accepted Web Standards

> <https://www.w3.org/WAI/standards-guidelines/wcag/>for

> accessibility (which is a requirement for the project)
>

> *

>
> PyQt5 would have the advantage of an installable binary
> but a similar behavior would be achievable with
> ElectronJs

> <https://www.electronforge.io/guides/framework-integration/react>which is a framework which allows compiling web applications targeting platforms like macOS, Windows, and Linux. (Needing an active internet connection would have been a disadvantage of the web based approach but it can be tackled with help of electron)
>
> *

>
> Easier to provide future updates (An installable made
> via PyQt5 would need to be manually updated) whereas a
> web based application updates whenever someone revisits
> the url with an active internet connection.
>

> *

>
> Easier to maintain, There are just simply more
> volunteers and developers in the web technologies ecosystem.
>
>
> Do let me know your thoughts, if you have any
> recommendations for the web application approach. I myself
> am interested in working on this project and would love your
> feedback. I myself am versed in such web technologies and
> would love to see this project to its end.
>
>

> --
>

[Riya Jain]

I just realized I replied specifically to a conversation rather than to the Google Group, So here I have squashed my last two replies. Apologies for the inconvenience.

1st Message

Hi Pratyush, Thanks for your input. I though, feel like some points you brought up were valid, a few of these could be thought of in a different way.

In your second point you bring up table editing to be a desktop task, though I feel like having the options for devices like tablets or other embedded systems with acces to the internet should also be considered.

And what you said about a constant internet connection, it won't be required because electron application would also be a one time download and install which will also be applicable to the PyQt application so yes, offline access would be there.

2nd message

I do agree with these points, and also wanted to clarify a little on the API point.

What I was envisioning when I brought up a web based GUI was a webpage encapsulating all the logic within the page itself (i.e : The frontend will contain all the logic, there will be no 

backend an thus API won't be provided)

If we integrate an API (a backend) we will need to have constant internet connection which might not be ideal but it would give us the plus point of being able to provision API to people who might require it but honestly, I do not see the use case for an API for such a task, please let me know if I am missing something.

Also, I think we can have a version selector to address the 3rd point as I see this issue to be persistent in both web version and the PyQt version, unless I am understanding the point incorrectly.

I'd agree, the entire community appears to be on the fence regarding this and the points going for both the cases appear to be highly valid especially the point that compiling for linux would be difficult which is true.

I'd wait to see what conclusion we reach.