Just as a piece of historical trivia, I’d like to quote Mike (Nov 30, 2006) concerning the estimated release date of a desktop version:
Maybe we can agree on “sometime in the 2020s”
Pleco Desktop
- Thread starter james
- Start date
Seriously though anyone finding themselves being unable to wait for a desktop version, just go chrome + Archon - I can't even tell you how many hours I've gotten out of it.
Shun
状元
Just as a piece of historical trivia, I’d like to quote Mike (Nov 30, 2006) concerning the estimated release date of a desktop version:
Maybe we can agree on “sometime in the 2020s”
Very nice! We also have to ask the question, would we rather be able to use Pleco 4.0 sometime soon, or use a web version. Here, I’d be in favor of Pleco 4.0.
Maybe the way the WhatsApp web interface does it, a web browser could talk to Pleco 4.0 running on one’s own mobile device through a gateway. That way, we’d have the larger screen, and the programming effort would likely be less than with a full-blown webserver. (Licensing should be easier, too, since it’s still running on one’s smartphone/tablet.) I've heard Pleco makes a transition to HTML internally with Pleco 4.0, anyway.
Shun
状元
I just think this solution has a few drawbacks:
- High memory requirements
- Archon is Chinese software, there's the possibility of rootkits being installed with it, perhaps not now, but maybe in the future.
- No copy and paste, or no good copy and paste
- Don't know about the licensing.
- Compatibility issues (sometimes)
If a web gateway were to make sense, I would be willing to pay $3-$5 a month for access to my own Pleco through it, that would be about $36-$60 dollars per year.
Of course, I'm open to counterarguments.
ctrl + c / ctrl + v
Shun
状元
I see, nice!
But it's plain text, not styled, right? Though I agree, that's not such a big issue.I see, nice!
Not totally sure on that one.
Isn't it written by some dude named Vlad from Toronto?
Shun
状元
Yes, it would probably be possible to make the clipboard HTML-based, but that would depend on both ARChon and Pleco.
You're right, sorry about the confusion (I once d/l'ed another emulation package from China.); so that point should be fine.
There are many solutions we can try to use - some will work for someone, some will do for others.
But I'm sure Pleco-on-the-Web is a next big step Pleco team will have to make sooner or later.
So it's not a question of "will they do?" but just a question "when they will do?".
As we already discussed before a web app can work online and offline, so web-step has much more power than just web-access to PIeco.
But I'm sure Pleco-on-the-Web is a next big step Pleco team will have to make sooner or later.
So it's not a question of "will they do?" but just a question "when they will do?".
As we already discussed before a web app can work online and offline, so web-step has much more power than just web-access to PIeco.
I'm not sure if we would actually be able to support offline use, for licensing reasons - very hard to DRM offline web browser content. Performance could also be a problem in a few places; SQLite is about an order of magnitude slower than the proprietary native database system we use, and with mobile / desktop CPU performance so close these days an all-SQLite web version on a desktop would actually be slower than a native-database version on a phone.
This would be more about a) access to Pleco from public computers, b) augmenting our mobile app for a few functions for which desktops might actually work better (creating flashcards, e.g.), and c) online sync of data; a companion to our mobile apps rather than a replacement for it. I don't think it's possible to create an equivalent experience to our mobile apps in a desktop web app, online or offline, and I don't think there's enough money in a native desktop app to justify developing one.
This would be more about a) access to Pleco from public computers, b) augmenting our mobile app for a few functions for which desktops might actually work better (creating flashcards, e.g.), and c) online sync of data; a companion to our mobile apps rather than a replacement for it. I don't think it's possible to create an equivalent experience to our mobile apps in a desktop web app, online or offline, and I don't think there's enough money in a native desktop app to justify developing one.
@mikelove ,
about offline:
1) what DRM issues worry you?
From technical POV I think the native app has the same issues as an offline web app could as Pleco stories all its data locally.
2) it's impossible to use "normal" SQL databases for offline usage without a native app helper/companion.
Without it offline usage requires a web browser web-storage usage. So the only way (without a native helper) is to use managed (JS-based) database engine/framework.
You don't need to move to another database format, just need to create such kind of engine/bridge to you proprietary database format.
As Pleco DB is a single-user DB and doesn't require complex transactions, database objects, etc. support I think it's not a big problem, just need some development resources. So you'll have the same DB format for any Pleco version.
In this case performance is not a problem - users will see no difference in performance between the native and the web apps.
In case of Pleco I'm sure an offline web app development has more sense than a desktop app development.
Moreover - except JS-engine for Pleco DB and some small offline-sipport parts, main part of the web app will be the same for online and offline usage, so it's a huge code reuse.
about offline:
1) what DRM issues worry you?
From technical POV I think the native app has the same issues as an offline web app could as Pleco stories all its data locally.
2) it's impossible to use "normal" SQL databases for offline usage without a native app helper/companion.
Without it offline usage requires a web browser web-storage usage. So the only way (without a native helper) is to use managed (JS-based) database engine/framework.
You don't need to move to another database format, just need to create such kind of engine/bridge to you proprietary database format.
As Pleco DB is a single-user DB and doesn't require complex transactions, database objects, etc. support I think it's not a big problem, just need some development resources. So you'll have the same DB format for any Pleco version.
In this case performance is not a problem - users will see no difference in performance between the native and the web apps.
In case of Pleco I'm sure an offline web app development has more sense than a desktop app development.
Moreover - except JS-engine for Pleco DB and some small offline-sipport parts, main part of the web app will be the same for online and offline usage, so it's a huge code reuse.
Last edited:
PS: native helpers for Pleco-DB support may be a better decision as "external" (for a browser) database is more flexible and can be shared among any installed browsers (web-storage is unique for every browser).
Anyway there's no problems with an offline solution, just some decisions consideration is required.
Anyway there's no problems with an offline solution, just some decisions consideration is required.
JD
状元
As an “old fart” who still reads paper newspapers (and gets it delivered to my house, even!) and has thousands of paper books, and had some of the first PC’s, and even an electronic typewriter with a word processor box attached, I have to really ask:
Is there any significant market, realistically, for WebPleco?
I don’t think it’s viable, and I think it’d be a waste of resources.
The world has moved on. If I go into a college class, the “kids” are all using their phones and tablets for everything. For myself, my PC sits in the next room nearly abandoned....the only time I use it is when a particular site is badly coded and won’t work on mobile Safari nor Chrome.
Yes, a full PC with multi-monitors is great (at work I use three monitors attached to my docking station and laptop), but the reality is who’s going to buy a PlecoWeb? Some minor fraction of the user base would want it. But the market is going to tiny compared to the mobile market.
I use Pleco when I’m sitting in my living room reading....with my iPad on the side table. I use it when I’m out at coffee with a Chinese colleague, and need to look it up on my iPhone.
Web technologies can be a back-end factor, but as a front-end interface, are dead.
Don’t spilt resources on a dead form-factor.
Edit: I’m mentally combining Web/Desktop into one thing, but didn’t clearly state it above.
JD
Is there any significant market, realistically, for WebPleco?
I don’t think it’s viable, and I think it’d be a waste of resources.
The world has moved on. If I go into a college class, the “kids” are all using their phones and tablets for everything. For myself, my PC sits in the next room nearly abandoned....the only time I use it is when a particular site is badly coded and won’t work on mobile Safari nor Chrome.
Yes, a full PC with multi-monitors is great (at work I use three monitors attached to my docking station and laptop), but the reality is who’s going to buy a PlecoWeb? Some minor fraction of the user base would want it. But the market is going to tiny compared to the mobile market.
I use Pleco when I’m sitting in my living room reading....with my iPad on the side table. I use it when I’m out at coffee with a Chinese colleague, and need to look it up on my iPhone.
Web technologies can be a back-end factor, but as a front-end interface, are dead.
Don’t spilt resources on a dead form-factor.
Edit: I’m mentally combining Web/Desktop into one thing, but didn’t clearly state it above.
JD
Shun
状元
I agree, and the $329 basic iPad is now much cheaper than before and perfectly capable of running Pleco. Android tablets can be even more affordable. All the available dictionaries combined cost a lot more than the hardware needed to run them on.
If the effort required to get it running were really low, I would be in favor of a Web/Desktop version, but that doesn’t seem to be the case.
If the effort required to get it running were really low, I would be in favor of a Web/Desktop version, but that doesn’t seem to be the case.
@Bvo - can't encrypt data; well, we could, but the source code would be much easier to reverse-engineer. I don't think there's a way we can effectively protect a database in an offline browser app. JS is faster than it used to be but not as fast as native; if the web app was the only app it'd be fast enough, but compared to our mobile apps it would feel slow. Native helper could work but then we start to wonder why we're not just doing an entirely native app - this is mainly meant to live online and I'm not inclined to put in a lot of effort to make it work offline.
@JD - this is why my main thinking is 'companion'; I do think there's a market for a really fantastic flashcard sync service with the ability to edit and perhaps even review a bit online. Bonus if it can also do other stuff like distribute live updates to databases in between app updates. Could also include other stuff - reading materials, exclusive flashcard lists, learning videos, audio, etc. (maybe work out deals with some other services to offer some of their content via our subscription - "Netflix for Chinese learning materials") And could use it as a better bridge between mobile and desktop than what we have now (import a flashcard file, add a new document to read, etc from our web interface). We have a lot of active users but not a lot of recurring revenue; I am firmly opposed to the idea of making our main product subscription-based, but getting even just a few % of our users to sign up for an add-on subscription of some sort would do a lot for our bottom line.
@JD - this is why my main thinking is 'companion'; I do think there's a market for a really fantastic flashcard sync service with the ability to edit and perhaps even review a bit online. Bonus if it can also do other stuff like distribute live updates to databases in between app updates. Could also include other stuff - reading materials, exclusive flashcard lists, learning videos, audio, etc. (maybe work out deals with some other services to offer some of their content via our subscription - "Netflix for Chinese learning materials") And could use it as a better bridge between mobile and desktop than what we have now (import a flashcard file, add a new document to read, etc from our web interface). We have a lot of active users but not a lot of recurring revenue; I am firmly opposed to the idea of making our main product subscription-based, but getting even just a few % of our users to sign up for an add-on subscription of some sort would do a lot for our bottom line.
@mikelove ,
I want to point to only one thing - a native helper for Pleco DB is a much simpler thing than whole app development.
And it requires no future development until DB formal will be changed (i.e. code-and-forget).
For Android and iOS these helpers are already ready
Today's JS-runtimes are very fast and used even on back-end (as it compiled to binaries anyway).
And Pleco is not a multi-user app that does complex operations in a real-time, so surely it will have no perfomance difference noticeable in any way.
The native app already has the data on a user side, so reverse-engineering is just the question of "easier or harder", not the question of possibility.
Sure, there is a good solution (depending on you current implementation) that will help to make a web-version not less secure than current native app.
Why do I think that Pleco for the Web is a promising solution ?
Well, it could be a very long discussion about pros and cons, but I want to point out some pros.
You already mentioned some good examples, just want to note that not only web-services and access-almost-everywhere are great things of the web, but web apps nature itself, as they're the most universal apps.
If you develop both online and offline web solutions - your app has no limits when and where one can use it.
Any OSes will do, even in case of a future OS - when it comes to masses it certainly will have a web browser, based on one of the most popular engine (Blink/WebKit?) and it means that your app is already works on a new platform!
There are some thing that will require native helpers (Screen Reader/OCR, some UX improvement things, etc.) but core functionality (dicts and flashcards) will already work.
At least online.
For core functionality offline support you'll need just add a Pleco DB native proxy app (or just have ready JS-based engine), but even without it online acces is ready.
But the main thing is development cost and time.
What is better - to create many apps for every platform or polish just one universal app, that could work online and offline on any platform?
The answer is obvious.
You'll have fully-shared code for any platform.
You can concentrate on the app functionality and not to fight with every OS/OS versions and device's bugs.
New functionalities/updates will be ready for every OS in the same moment and users have no wait until you make the app ready for there preferred OS.
All development time you can spend on real app improvements, not to make the app just work on other platform - it means users will have better app, faster delivery of new/updated functionality and Pleco will grow faster.
Etc....
I think the main point is clear
It's not so easy as it sounds, but is worth efforts.
I want to point to only one thing - a native helper for Pleco DB is a much simpler thing than whole app development.
And it requires no future development until DB formal will be changed (i.e. code-and-forget).
For Android and iOS these helpers are already ready
Today's JS-runtimes are very fast and used even on back-end (as it compiled to binaries anyway).
And Pleco is not a multi-user app that does complex operations in a real-time, so surely it will have no perfomance difference noticeable in any way.
The native app already has the data on a user side, so reverse-engineering is just the question of "easier or harder", not the question of possibility.
Sure, there is a good solution (depending on you current implementation) that will help to make a web-version not less secure than current native app.
Why do I think that Pleco for the Web is a promising solution ?
Well, it could be a very long discussion about pros and cons, but I want to point out some pros.
You already mentioned some good examples, just want to note that not only web-services and access-almost-everywhere are great things of the web, but web apps nature itself, as they're the most universal apps.
If you develop both online and offline web solutions - your app has no limits when and where one can use it.
Any OSes will do, even in case of a future OS - when it comes to masses it certainly will have a web browser, based on one of the most popular engine (Blink/WebKit?) and it means that your app is already works on a new platform!
There are some thing that will require native helpers (Screen Reader/OCR, some UX improvement things, etc.) but core functionality (dicts and flashcards) will already work.
At least online.
For core functionality offline support you'll need just add a Pleco DB native proxy app (or just have ready JS-based engine), but even without it online acces is ready.
But the main thing is development cost and time.
What is better - to create many apps for every platform or polish just one universal app, that could work online and offline on any platform?
The answer is obvious.
You'll have fully-shared code for any platform.
You can concentrate on the app functionality and not to fight with every OS/OS versions and device's bugs.
New functionalities/updates will be ready for every OS in the same moment and users have no wait until you make the app ready for there preferred OS.
All development time you can spend on real app improvements, not to make the app just work on other platform - it means users will have better app, faster delivery of new/updated functionality and Pleco will grow faster.
Etc....
I think the main point is clear
It's not so easy as it sounds, but is worth efforts.
Last edited:
JD
状元
@Bvo
My opinion: One-app-deployed-everywhere is great in theory. The reality is you are forced to drop down to the lowest-common-denominator. So, you end up deploying “crud” to everybody.
Then, since the experience is poor, people don’t buy the content, revenue drops, and you turn off the shop’s lights.
I’ll pay for a better experience. I won’t pay for run-of the-mill.
My opinion: One-app-deployed-everywhere is great in theory. The reality is you are forced to drop down to the lowest-common-denominator. So, you end up deploying “crud” to everybody.
Then, since the experience is poor, people don’t buy the content, revenue drops, and you turn off the shop’s lights.
I’ll pay for a better experience. I won’t pay for run-of the-mill.
@JD,
as I wrote it's no so easy as in theory.
But you see web sites/apps everywhere - are they all poor and crud?
I bet, even this forum you access through a "poor" web browser and not a "great" native app (do you know they exist?)
Web-technologies are mature enough today so everything depends on developers - poor developers create poor apps, great developers create great apps.
IT world is growing very fast and it's better to be ready for tomorrow, because tomorrow there will be another demands, even if old-fashioned people will still alive. Someone can stick on Windows XP "just because it works", but many today young people even don't know what it is.
It's not about better or worse, it's about evolution.
Noone says you should drop your habits, but your habits are not one-size-fits-all thing.
as I wrote it's no so easy as in theory.
But you see web sites/apps everywhere - are they all poor and crud?
I bet, even this forum you access through a "poor" web browser and not a "great" native app (do you know they exist?)
Web-technologies are mature enough today so everything depends on developers - poor developers create poor apps, great developers create great apps.
IT world is growing very fast and it's better to be ready for tomorrow, because tomorrow there will be another demands, even if old-fashioned people will still alive. Someone can stick on Windows XP "just because it works", but many today young people even don't know what it is.
It's not about better or worse, it's about evolution.
Noone says you should drop your habits, but your habits are not one-size-fits-all thing.
Last edited:
@JD,
BTW, I mentioned already that using web-app as a core has benefits not for developers only, but for users too.
Everybody here wants v4.0 ASAP.
But just imagine you could have in 1-2 years all features Pleco team currently could bring only once in 5-6 years and with the same quality they do now.
10 years ago they planned a desktop version, but they didn't developed it and it seems not so much important for today.
Now they have another plans but who knows when they could bring them to a life and how much people will be interested in that things when they'll be finished?
So not a move to a new technology will really come to "turn off the shop's lights" but sticking on old technologies will do.
May be you do not believe that development cycle could be shortened and bring more and better, but it's just a question of your beliefs
BTW, I mentioned already that using web-app as a core has benefits not for developers only, but for users too.
Everybody here wants v4.0 ASAP.
But just imagine you could have in 1-2 years all features Pleco team currently could bring only once in 5-6 years and with the same quality they do now.
10 years ago they planned a desktop version, but they didn't developed it and it seems not so much important for today.
Now they have another plans but who knows when they could bring them to a life and how much people will be interested in that things when they'll be finished?
So not a move to a new technology will really come to "turn off the shop's lights" but sticking on old technologies will do.
May be you do not believe that development cycle could be shortened and bring more and better, but it's just a question of your beliefs