Pencil – an open-source GUI prototyping tool for all platforms(github.com)
github.com
Pencil – an open-source GUI prototyping tool for all platforms
https://github.com/evolus/pencil
93 comments
Pencil is awesome. It is my goto prototyping and wireframing tool. I honestly like it better than the other tools with price tags that I've used out there. Somehow it seems noone knows about this, but its doing for mockups/wireframing what Blender does for 3D artists - providing a high quality open source tool that is usable by industry professionals. I hope pencil and their devs get more recognition / funding.
using it and thinking about contributing it for long.
The team did really ambitious work of dumping XUL and rewriting it in Javascript + HTML. I was one of the first user of new version since they hosted in gitlab , i was astonished that they did the conversion from XUL within just around a month and already working since then.
I've been an occasional user of Pencil for 5 years (almost to the month). Really glad to see it moving away from XUL.
But they're moving to Electron which I wish packed lighter.
> Really glad to see it moving away from XUL.
Why?
Why?
Because XUL will soon be unmaintained. It's too useful a tool to wither away and die.
You may want to take a look at this http://www.zdnet.com/article/mozilla-changes-firefox-apis-de...
Yes, I know. I am one of those "unhappy developers". I had hoped to find some reasoning behind OP's joy of getting rid of XUL. In my opinion XUL is what made Pencil so attractive (native widgets, that can be stuffed with behaviour), Using XUL and an add-on Pencil could have become a full fledged GUI designer, using XSLT to export to various formats.
Been using this for a while in it's various incarnations - this one is definitely the best so far.
Very useful tool for UI prototyping.
Very useful tool for UI prototyping.
Pencil was my go to free wireframing app for some time. Great to see that they are updating it.
May I ask why you don't use it anymore?
I still like it quite a lot but I find sharing content and collaborating is easier in some of the other apps.
Note: I haven't tried the new version yet, so they may be working on this.
Note: I haven't tried the new version yet, so they may be working on this.
New Version have improved a lot in many areas. I find it a lot easier and distraction free compare to other tools.
It get things done easily ( Bootstrap / Material mockup UIs are KILLER!)
I had used Balsamiq to design the forms/screens for a SaaS project for a client (collaboratively with them), and it was not bad. IIRC, response was a little laggy, which might have been because it was built using Adobe AIR (not sure). (I got a free copy of it from Peldi under their scheme for people who develop free / open source software projects.)
Has anyone tried Axure (paid product), and if so, how did you find it? Another client that I did a project for, had claimed it was good, when I told him I use Balsamiq.
Has anyone tried Axure (paid product), and if so, how did you find it? Another client that I did a project for, had claimed it was good, when I told him I use Balsamiq.
Hey everyone! Vim Girl here. I've just created a demo of Pencil! If you are interested in seeing how pencil works I built a simple page: https://youtu.be/KTcYMvENb0k
Pencil has many higher-res stencils now, but I prefer the old ones that actually look like Pencil drawings.
I have also given this to clients, to have them draw their own UI concepts (as a starting position / way of communicating) with good results.
I have also given this to clients, to have them draw their own UI concepts (as a starting position / way of communicating) with good results.
Wow looks better than balsamiq I will try this out at work.
balsamiq is a fast compiled Flash application, this will be an Electron one, and is XULRunner one currently.
What's your point?
Native versus web app.
Calling a compiled Flash app "native" is a bit of a stretch.
Love pencil and started looking to contribute late last year. Unfortunately I couldn't get it to build properly on MacOS. As a result I couldn't get anything to run, and with practically no documentation at the time I eventually moved on. Hopefully the situation has improved over the year. I'll give it another go soon and see what can be done.
[deleted]
[deleted]
Sketch, Axure, Balsamiq.... and I still go back to Pencil + Illustrator after all these years.
How did you find Axure?
I use Axure daily, but only after trying pretty much every other wireframing and prototyping tool first. It always looked too ugly and expensive, the Word of wireframing.
Having finally got to grips with it, in my experience it blows away everything else. Nothing else compares in terms of features or workflow.
But it's still ugly and expensive.
Having finally got to grips with it, in my experience it blows away everything else. Nothing else compares in terms of features or workflow.
But it's still ugly and expensive.
Interesting, thanks for the reply.
Very instable on Linux unfortunatly.
As far as I know, most of Pencil developers are on Linux so Pencil is literally developed and tested on Linux most of the time.
Today, Pencil reached the #1 spot on both of GitHub trending lists (repositories http://i.imgur.com/4SRsna1.png and developers http://i.imgur.com/JrqTy3k.png).
I can understand that you had some issues with Pencil on Linux but claiming that Pencil is very unstable on Linux is a bit uninformed given its validated quality.
Today, Pencil reached the #1 spot on both of GitHub trending lists (repositories http://i.imgur.com/4SRsna1.png and developers http://i.imgur.com/JrqTy3k.png).
I can understand that you had some issues with Pencil on Linux but claiming that Pencil is very unstable on Linux is a bit uninformed given its validated quality.
Head over to their GitHub page and post your issue. They're pretty responsive.
I prefer to pay for a stable solution than spend my time on improving an unstable one. Funny, when I was younger it was the contrary.
Can't confirm.
Did they really need Electron for this? Why not just make it also available as a normal web app with a URL?
I see a lot of criticism around Electron. I honestly admit I am not a fan of it - see Slack memory consumption. OTOH I am not experienced enough to be able to judge the language as a whole. Could anyone not biased list pros and cons of Electron here? If it is so bad as people say, why more and more Electron apps pop up here and there?
I'm probably a _bit_ biased in favor of Electron, but I feel like I can give a pretty reasonable rundown of the pros and cons.
Pros: - Chromium is a mature, open-source project which shows no signs of going anywhere anytime soon. - Electron allows web developers to use well-understood tools (Chromium/v8, Node/v8) to build web applications with additional, non-Web capabilities in a predictable runtime environment. - Browsers are the most consistent (and consistently available) GUI environment across platforms. - Some of the bigger value-add capabilities (filesystem/device access, windowing, native menus) don't necessarily benefit from native code- the Electron and Node APIs are good enough. - Electron is well-documented, free as in beer, and there are a ton of examples and demo apps.
Cons: - Memory usage, obviously. Chrome's biggest selling point was its ability to share resources among tabs (cutting down on memory requirements) which goes straight out the window when each app needs its own instance of Chromium. - Disk usage, obviously. Each Electron package includes the entire modified-Chromium binary it was built with. - Many Electron apps fail to take advantage of the main/renderer process split, because of the easy access to Electron APIs inside renderer processes. - Packaging/building/signing/auto-updating still have a very poor developer experience, and are not consistent across platforms. - It's too easy to open up security holes by opening remote resources in a renderer process with Node integration on. (Personally, if there's one thing I'd change about Electron, this is it.)
To tell the truth, I see Electron as a stepping stone for the Javascript community. It proves that there's great interest in doing cross-platform native app development under Javascript. Personally, I'm hoping that after React 16 (with Fiber) launches, we'll see work on a React Native-like framework which fills the gap currently bridged by Electron.
Pros: - Chromium is a mature, open-source project which shows no signs of going anywhere anytime soon. - Electron allows web developers to use well-understood tools (Chromium/v8, Node/v8) to build web applications with additional, non-Web capabilities in a predictable runtime environment. - Browsers are the most consistent (and consistently available) GUI environment across platforms. - Some of the bigger value-add capabilities (filesystem/device access, windowing, native menus) don't necessarily benefit from native code- the Electron and Node APIs are good enough. - Electron is well-documented, free as in beer, and there are a ton of examples and demo apps.
Cons: - Memory usage, obviously. Chrome's biggest selling point was its ability to share resources among tabs (cutting down on memory requirements) which goes straight out the window when each app needs its own instance of Chromium. - Disk usage, obviously. Each Electron package includes the entire modified-Chromium binary it was built with. - Many Electron apps fail to take advantage of the main/renderer process split, because of the easy access to Electron APIs inside renderer processes. - Packaging/building/signing/auto-updating still have a very poor developer experience, and are not consistent across platforms. - It's too easy to open up security holes by opening remote resources in a renderer process with Node integration on. (Personally, if there's one thing I'd change about Electron, this is it.)
To tell the truth, I see Electron as a stepping stone for the Javascript community. It proves that there's great interest in doing cross-platform native app development under Javascript. Personally, I'm hoping that after React 16 (with Fiber) launches, we'll see work on a React Native-like framework which fills the gap currently bridged by Electron.
they keep popping up because they are piss easy to make and offer a runtime on all platforms.
Development time can be cut down, in exchange for a hindered performance on the client
Development time can be cut down, in exchange for a hindered performance on the client
Slack really doesn't make sense as they already make native apps for mobile devices in Xamarin (.Net), but small projects like this do make sense, as the amount of human resources justification is clearly there.
developing for electron or nw.js is wierd as you mix in code that would usually run on a server. the advantage of using electron or nw.js is that you dont have to support all kind of weird browsers. but then it wont run on most mobile phones. so if you want to target mobile make a web app. if you only target pc and want to support both mac linux and windows then there are few alternatives for a gui app.
Maybe because they'v been releasing desktop apps for all the previous versions, and doing an Electron app could make users more comfortable with it.
Also, Pencil doensn't need high performance requirements, si Electron could be perfectly valid for it (and im not a big fan of it)
Also, Pencil doensn't need high performance requirements, si Electron could be perfectly valid for it (and im not a big fan of it)
This allows working offline and saving work locally using the native filesystem. A significant improvement over a webapp. My preference goes Full native app > electron >> webapp.
I rather have native app > webapp.
Really don't get the point of Electron, as I never got the point of XULRunner before.
If it is to be a webapp, take advantage of HTML5 features for offline apps, if it is to be native then take advantage of the OS UI/UX features.
Something in the middle just feels schizophrenic from UI/UX point of view.
Really don't get the point of Electron, as I never got the point of XULRunner before.
If it is to be a webapp, take advantage of HTML5 features for offline apps, if it is to be native then take advantage of the OS UI/UX features.
Something in the middle just feels schizophrenic from UI/UX point of view.
Just a reminder that you're talking about an open source project, sustained entirely by volunteers. I'm sure they'd rather have people contributing, or speaking through their financial donations > complaining that they don't have the resources to write native versions for every platform.
The bottom line is that cross-platform desktop development is HARD.
Qt and Wx eventually push you toward C++, which few people under the age of 40 want to learn. GTK looks awful on every platform.
JavaFX is actually quite nice now, and embedding a Java runtime takes up no more space than embedding Chrome. But you still have to deal with sluggish startup times, and similar complaints as C++... that Java isn't "cool" now, or whatever.
So if you want something that looks decent on Windows, OS X, and Linux, and is written in languages that 19-year olds approve of, then your options are:
1. Write separate native versions for each platform, using C# for Windows, Swift for OS X, and whatever for Linux, or
2. Electron.
If you're a commercial entity, selling products or services for money in the face of competition, then you should probably go with option #1. If you're an open source project or hobbyist, then just go with #2 and take solace in the fact that the people bitching were never going to contribute regardless.
The bottom line is that cross-platform desktop development is HARD.
Qt and Wx eventually push you toward C++, which few people under the age of 40 want to learn. GTK looks awful on every platform.
JavaFX is actually quite nice now, and embedding a Java runtime takes up no more space than embedding Chrome. But you still have to deal with sluggish startup times, and similar complaints as C++... that Java isn't "cool" now, or whatever.
So if you want something that looks decent on Windows, OS X, and Linux, and is written in languages that 19-year olds approve of, then your options are:
1. Write separate native versions for each platform, using C# for Windows, Swift for OS X, and whatever for Linux, or
2. Electron.
If you're a commercial entity, selling products or services for money in the face of competition, then you should probably go with option #1. If you're an open source project or hobbyist, then just go with #2 and take solace in the fact that the people bitching were never going to contribute regardless.
> C++, which few people under the age of 40 want to learn
Thanks for making us aware that it is going to be easier to find jobs in High Performance Computing, Fintech, Games, OS and compiler development, machine learning, GPGPU computing, robotics, automotive industry, database engines, audio processing, medical devices, IoT,....
Thanks for making us aware that it is going to be easier to find jobs in High Performance Computing, Fintech, Games, OS and compiler development, machine learning, GPGPU computing, robotics, automotive industry, database engines, audio processing, medical devices, IoT,....
Learn COBOL or RPG, and the world will really be your oyster.
Not criticizing C++ (I'm in my 40's and spent the first several years of my career working with it). Just stating the reality of what people whine about on web forums (when they're not whining that open source developers should do even more free work).
Not criticizing C++ (I'm in my 40's and spent the first several years of my career working with it). Just stating the reality of what people whine about on web forums (when they're not whining that open source developers should do even more free work).
The thing with these youngsters, is than they eventually see that the old guys had some point.
https://news.ycombinator.com/item?id=14613142
https://news.ycombinator.com/item?id=14613142
> JavaFX is actually quite nice now, and embedding a Java runtime takes up no more space than embedding Chrome. But you still have to deal with sluggish startup times,
Startup time for JavaFX is just terrible even in comparison to Electron.
Startup time for JavaFX is just terrible even in comparison to Electron.
Only if you don't AOT compile to native code, which many on HN seem to keep forgetting about.
There are plenty of options available among commercial JDK vendors, but if you don't want to spend money, ExcelsiorJet has free licenses for non-commercial use.
https://www.excelsiorjet.com/free
There are plenty of options available among commercial JDK vendors, but if you don't want to spend money, ExcelsiorJet has free licenses for non-commercial use.
https://www.excelsiorjet.com/free
I agree it quite outrageous all the RAM & Size on disk & CPU an electron app requires. But on the other hand what are the other alternative for a one codebase multiplatform app ?
Real OS native UI requires a re-write on each platform unless using libui which is limited to a button, a checkbox and a slider (okay for little app but you won't build a full blown UI editor out of that)
Then there is GTK but it has lots of problems when you want to maintain a multiplatform app, looks ugly on other platform than linux, and performance is not amazing (but with GTK4 and the vulkan renderer it might improve I guess)
At last the only real solution is QT (so it's not like there are zillions of solutions on the native side, there's only QT basically). And with QT if you use C++ then there's no package manager, all that prehistoric qmake stuff , etc... Also visually speaking QT is no more native than HTML, it has to emulate the style of the OS but is not using native OS widgets
Also Electron might feel super heavy, but in the future we might one day have Servo (which seems even more efficient that QT by doing everything on the GPU (just as an example it does glyphs rasterisation on GPU unlike QT)) with either javascript (in this case it will be kind of the same as QT + QML&JS) or with WebAssembly. And concerning the size on disk we could provide it as a dependence common to all app using it (for eg as a FlatPack Runtime on linux).
So right now Electron is outrageous but in the future the situation might improve a lot (with an alternative based on Servo if it ever happens)
Real OS native UI requires a re-write on each platform unless using libui which is limited to a button, a checkbox and a slider (okay for little app but you won't build a full blown UI editor out of that)
Then there is GTK but it has lots of problems when you want to maintain a multiplatform app, looks ugly on other platform than linux, and performance is not amazing (but with GTK4 and the vulkan renderer it might improve I guess)
At last the only real solution is QT (so it's not like there are zillions of solutions on the native side, there's only QT basically). And with QT if you use C++ then there's no package manager, all that prehistoric qmake stuff , etc... Also visually speaking QT is no more native than HTML, it has to emulate the style of the OS but is not using native OS widgets
Also Electron might feel super heavy, but in the future we might one day have Servo (which seems even more efficient that QT by doing everything on the GPU (just as an example it does glyphs rasterisation on GPU unlike QT)) with either javascript (in this case it will be kind of the same as QT + QML&JS) or with WebAssembly. And concerning the size on disk we could provide it as a dependence common to all app using it (for eg as a FlatPack Runtime on linux).
So right now Electron is outrageous but in the future the situation might improve a lot (with an alternative based on Servo if it ever happens)
Like we used to do in the good old days, before this Web 2.0 craziness, and many comercial apps still do.
Create a small wrapper layer for the supported OSes, which is the option used by most comercial software actually, like Adobe or Office, and many others.
Electron apps basically put the confort of developer in front of the user they are supposed to serve.
Create a small wrapper layer for the supported OSes, which is the option used by most comercial software actually, like Adobe or Office, and many others.
Electron apps basically put the confort of developer in front of the user they are supposed to serve.
There is one more thing. Developing in HTML5/JS (with all its ecosystem) is freaking fast in terms of developer productivity. You will probably build full fledge app in shorter time using JS than with C++. So you can deliver MVP to the market faster = profit $$$
And initial group of users are early adaptors anyway. They are usually eager to try new applications even if they are not perfect.
The problem is: "what next?", when users will start complaining about speed or other things.
Should company rewrite original HTML5 based MVP to C++ to gain speed?
Or should they optimize existing HTML5 solution? (many HTML5 apps are running with nearly native responsiveness).
Or something else? Or maybe HTML5 even for MVP is a bad idea?
And initial group of users are early adaptors anyway. They are usually eager to try new applications even if they are not perfect.
The problem is: "what next?", when users will start complaining about speed or other things.
Should company rewrite original HTML5 based MVP to C++ to gain speed?
Or should they optimize existing HTML5 solution? (many HTML5 apps are running with nearly native responsiveness).
Or something else? Or maybe HTML5 even for MVP is a bad idea?
How did you make the conclusion that JS is faster than C++? An experienced C++ developer, or better yet, an experience C++ developer team, moves “freaking” fast. The only advantage to the HTML/JS stack is you can get cheap labor from dime a dozen web “devs”. That’s it.
Case in point, look at Atom. Let’s assume your “MVP”, “profit $$$” and what not is somewhat correct. Yet, the amount of engineering time and effort it has taken to optimize that tech to fix things that are trivial in the native world is staggering. How does that fit in your “profit $$$” equation, as an initial core team of experienced C++ developers would have developed with these issues in mind and created a product that is viable in the same scenarios.
Case in point, look at Atom. Let’s assume your “MVP”, “profit $$$” and what not is somewhat correct. Yet, the amount of engineering time and effort it has taken to optimize that tech to fix things that are trivial in the native world is staggering. How does that fit in your “profit $$$” equation, as an initial core team of experienced C++ developers would have developed with these issues in mind and created a product that is viable in the same scenarios.
Ok, maybe I will reconsider C++.
But if you were building such app in C++ what third part solutions would you recommend for building multiplatform GUI? Qt? GTK? What is used now and what will be working/looking good on all three main platforms? (Mac/Linux/Windows)
But if you were building such app in C++ what third part solutions would you recommend for building multiplatform GUI? Qt? GTK? What is used now and what will be working/looking good on all three main platforms? (Mac/Linux/Windows)
Fuck user experience! All that matters to “developers” these days is “hackablility” and “velocity”. The user suffers? It’s his fault he is not using a better device.
I agree it quite outrageous all the RAM & Size on disk & CPU an electron app requires. But on the other hand what are the other alternative for a one codebase multiplatform app?
If the program fulfills their needs well enough, users don't care what it's written in or how fat it is.
And multi-platform matters. I've seen blog posts on how to get Sketch running on Windows using a Mac VM. Talk about using system resources.
If the program fulfills their needs well enough, users don't care what it's written in or how fat it is.
And multi-platform matters. I've seen blog posts on how to get Sketch running on Windows using a Mac VM. Talk about using system resources.
I think Atom gave bad fame to the Electron (it's ironically because Electron was made for Atom).
Atom is bloated and slow and people think that each Electron(or Chromium) app is bloated and slow.
But for example VSCode is a lot faster (and consumes less RAM, from what I just checked) than Atom. So it's not Electron to blame...
Atom is bloated and slow and people think that each Electron(or Chromium) app is bloated and slow.
But for example VSCode is a lot faster (and consumes less RAM, from what I just checked) than Atom. So it's not Electron to blame...
Not only Electron to blame. Electron still gets a decent share of the blame, simply because it's a memory and CPU hungry runtime.
Many consumer laptops are still shipping with only 4 gigs of ram - that's not a lot of space for Electron apps.
Many consumer laptops are still shipping with only 4 gigs of ram - that's not a lot of space for Electron apps.
I noticed you've been downvoted. I find it amusing the expectations some people have about the hardware consumers should be running. While many on here, being a geek community and all, will have relatively decent systems; most normal people would rather keep a system as long as they can. Not to mention those in poorer communities or countries who cannot afford newer tech.
In fact it was only this year when I upgraded a work colleagues personal laptop from 2GB to 4GB.
In fact it was only this year when I upgraded a work colleagues personal laptop from 2GB to 4GB.
Meta:
Downvoting is an accepted method of disagreement on HN. It's a problematic stance IMO since downvotes grey out the text, making dissenting opinions impossible to make out if they're unpopular enough.
Back on topic, 4GB laptops are incredibly common, especially in retail stores. Getting a laptop with 8 GB of memory frequently requires looking online (most folks still buy their computers from retail stores) and customizing your order.
For example, I just visited both Dell and System76, and except for the gaming laptops, all of them default to 4GB of ram, and adding more (while not terribly expensive) requires thought and action on the consumer's part.
Downvoting is an accepted method of disagreement on HN. It's a problematic stance IMO since downvotes grey out the text, making dissenting opinions impossible to make out if they're unpopular enough.
Back on topic, 4GB laptops are incredibly common, especially in retail stores. Getting a laptop with 8 GB of memory frequently requires looking online (most folks still buy their computers from retail stores) and customizing your order.
For example, I just visited both Dell and System76, and except for the gaming laptops, all of them default to 4GB of ram, and adding more (while not terribly expensive) requires thought and action on the consumer's part.
It's interesting. What browsers do people use on this machines? Though according to wikipedia most popular browser is Chrome:
https://en.wikipedia.org/wiki/Usage_share_of_web_browsers
but it seems weird, because Chrome is such a memory monster (it usually takes almost all RAM memory you have on your machine and additionally disk space if you are running of RAM). I have 16GB ram and Chrome takes me 10GB of it and ~1GB of disk space.
but it seems weird, because Chrome is such a memory monster (it usually takes almost all RAM memory you have on your machine and additionally disk space if you are running of RAM). I have 16GB ram and Chrome takes me 10GB of it and ~1GB of disk space.
I've been downvoted because HN has Dislike Button which encourages people to downvote things they personally don't like instead of making constructive arguments ;)
If it's any consolation I did provide a counterargument and got downvoted for it.
As for the 'flag', that's not the same as downvoting. Or at least shouldn't be used in the same way although I have lately seen a disappointing number of comments marked as "flagged" which shouldn't have been. (There's some guidance about flagging posts here: https://news.ycombinator.com/newsguidelines.html). Downvoting is something that's only available to members above a specific karma threshold (2000 IIRC).
As for the 'flag', that's not the same as downvoting. Or at least shouldn't be used in the same way although I have lately seen a disappointing number of comments marked as "flagged" which shouldn't have been. (There's some guidance about flagging posts here: https://news.ycombinator.com/newsguidelines.html). Downvoting is something that's only available to members above a specific karma threshold (2000 IIRC).
I upvoted you.
BTW how to downvote comments on HN? I sometimes "flag" them to mark as downvote, but I'm not sure if flag is the same as downvote.
You need karma > 500 to downvote. And even then, you cannot downvote replies to your own comments etc.
> I think Atom gave bad fame to the Electron
And GitHub “desktop” client, and Slack “desktop” “app”, and Git Kraken… The list goes on.
I've found every Electron app I've used to be terrible. This includes VSCode. In fact compare VSCode to Adobe Brackets - both of which are using web technologies as their framework but Brackets is a node.js application while VSCode is Electron, and you'll see just how badly Electron performs when even compared to similar technologies.
I used Brackets maybe 2 years ago and it was very slow back then. Maybe now they have optimized it, I don't know.
Oh it's definitely slow compared to the likes of Sublime Text or vim. But compared to Atom, VSCode, etc Brackets feels a lot snappier and less memory hungry.
This is what I've experienced on 4 different hardware platforms however all running ArchLinux so YMMV.
This is what I've experienced on 4 different hardware platforms however all running ArchLinux so YMMV.
[deleted]
VSCode is visibly slower than Emacs on my Ubuntu travel netbook.
I only use it due to its Rust's support.
I only use it due to its Rust's support.
From the UX point of view working with local files without logging in somewhere is very precious.
From the dev point of view Electron provides the fastest way to make cross-platform app in high-level language.
Only if the she/he doesn't know any other tech besides web.
Electron apps are the clear example of putting developer comfort before the user UI/UX.
Electron apps are the clear example of putting developer comfort before the user UI/UX.
“Developer comfort” are strong words. It’s putting JS web “dev” comfort, as I certainly wouldn’t feel comfortable writing anything in JavaScript.
There's always a lot of hate for anything Electron, so I'll just pipe up and say I am happier that they provide it as an offline app rather than having it online and needing me to have a tab in Chrome open. I know Electron isn't perfect but for regular users (those outside of the HN sphere) I don't think they really think about this much.
Pencil is a small enough project (10 contributors on Github) - I doubt they have resources (time or money) available to put web infrastructure behind it and maintain that - which would be a major distraction from their real goal.
Pencil is a small enough project (10 contributors on Github) - I doubt they have resources (time or money) available to put web infrastructure behind it and maintain that - which would be a major distraction from their real goal.
LeoNatan25(1)
apps made with i-cant-learn-the-proper-language-so-i-just-use-one-thats-not-made-for-the-job always feel and perform very badly. at least for me.
i mean they call out performance issues right in the first paragraph in the readme.
terrible world of half-assed pseudo-native applications.
i mean they call out performance issues right in the first paragraph in the readme.
terrible world of half-assed pseudo-native applications.
What language and GUI framework do you suggest ?
"Can't learn" is rarely the issue. Supporting two or three separate native apps is.
For some organizations this is manageable and the right move. For others, resources need to be allocated otherwise and they take the path of least resistance.
Most non technical people don't know the difference, aren't checking ram usage, don't have philosophical opposition to writing desktop apps in a browser, etc.
If my choice was between writing real native apps and slowing development versus just getting something done, I'd choose the latter, particularly for a project like this one. I understand the complaint, but in practice it's often a developer's quibble.
For some organizations this is manageable and the right move. For others, resources need to be allocated otherwise and they take the path of least resistance.
Most non technical people don't know the difference, aren't checking ram usage, don't have philosophical opposition to writing desktop apps in a browser, etc.
If my choice was between writing real native apps and slowing development versus just getting something done, I'd choose the latter, particularly for a project like this one. I understand the complaint, but in practice it's often a developer's quibble.
http://www.fiftythree.com/pencil
https://www.apple.com/apple-pencil/
Kind of already an established name in the Apple world.
Kind of already an established name in the Apple world.
I recall using this for some prototype work around fall 2011. Apple's claim to the word was moot before this application existed.
Yep, the commit history in the old repo goes back to 2008: https://code.google.com/archive/p/evoluspencil/source/defaul...
We really should considering using this in Libreoffice mockups :-)
Can confirm, I also used this at least 4 years ago.
This has been around a lot longer than Apple's products.
https://www.apple.com/apple-pencil/ https://en.wikipedia.org/wiki/Pencil
Kind of already an established name in the English-speaking world.
Serious talk though, this kind of comment is worthless.
Kind of already an established name in the English-speaking world.
Serious talk though, this kind of comment is worthless.
Why is it worthless? There's probably a trademark issue somewhere: http://tmsearch.uspto.gov/bin/showfield?f=doc&state=4801:lah...
Not that I really care... but there are too many damned pencils now. I vote apple rename theirs.
Not that I really care... but there are too many damned pencils now. I vote apple rename theirs.