Started from the bottom, now we're near: 16 years on, open-source vector graphics editor Inkscape draws close to v1.0 Inkscape, a popular open-source vector graphics application, is heading for its 1.0 release more than 16 years after its first appearance in November 2003. The Inkscape team has released two updates, one to fix issues with the current version, and the other a release candidate for 1.0. The application runs on Windows, Linux …
I had always liked Corel Draw - had some of the best vector clipart as part of the package - stuff that was genuinely useful - not just cheesy graphics to torture people forced to listen to my PowerPoint sermons (although that is clearly a worthy use).
Only recently came across inkscape and it is very good indeed - now have migrated from OSX and Illustrator, to POP-OS (tech/ analyst focused Ubuntu) having a product that doesn't try to fleece and / or update me every 5 minutes is a welcome change.
[are there any good vector graphics libraries any more?]
I preferred DesignWorks from GST / GSP rather than Corel. Text to a line/curve/shape was easy to use. But they started concentrating on budget SW for win9x, lots of instability on 2K XP and then I was doing other things and didn't need Vector art much. I did install Inkscape on Linux and use it a few times.
I'm still running Micrografx Draw from the Win 95 days on Windows 10 64 bit. It still does everything I want and need. It is 32 bit, but the installer was 16 bit. Changed the installer and everything works. I do have Corel Draw loaded and it actually (still) imports the Micrografx format as they bought out Micrografx drawing apps decades ago. If it ain't broke, don't fix it.
I realize that your's is an older post, but I am trying to get Micrografx to run on my Win 10 unit. I am very fond of Micrografx and was disappointed when I could not get it to install. Could you enlighten me as to how you were able to install it on your machine?
Thank you for your time,
Fred P.
Don't forget to set your page size preference to "letter", if you are this side of the pond. to get that set as a permanent preset is non-intuitive.
Also, for some strange reason some CUPS driver;less printer setup refused to print from Inkscape directly, I had to do PDF first, then print, until I gave up and hunted for an arcane Brother printer driver to regain full happy.
Bring back Quarto and Foolscap, that'll fool 'em. Somehow my grandfather obtained a job lot of Quarto back in the 1970s, green and blue and orange - no white - and for years afterwards all the Sunday school, Girls' Brigade, youth club, school notices etc. were printed on that size paper on a Gestetner, first using stencils produced on my grandfather's electric typewriter, then my LX80 dot-matrix.
Pretty sure there's a half a box of green still knocking about somewhere. Probably in mum's attic.
M.
Under the covers the big change in version 1.0 is the switch to the GTK+ 3 library.
They should have just gone the extra mile and switched to Qt. I know, it's not easy, but the energy behind GTK+ as a cross-platform toolkit is waning, while Qt was, and still is, designed for exactly that purpose. Wireshark, VLC, and other popular cross-platform software tells the compelling story.
GTK+ on Windows and Mac is kind of an ugly hack, and still carries a lot of weird GNOME-isms with it. In the words of Gollum: "Curse the de Icaza, we hates it forever!"
Speaking as someone who downloaded Qt Creator a week or so ago and has played around with the samples, Qt on the Mac also isn't especially well-integrated. Widgets mostly look native, but act oddly — e.g. the scrolling in Qt Creator's own list of available samples responds to two-finger swipes and shows a scroll bar that looks about right and can be grabbed, but has its own completely unique sense of scrolling speed and momentum, entirely distinct from that of every native scroll area.
Most obviously terrible was the MDI sample, which obviously was always going to be pretty painful because the Mac doesn't normally do MDI, but it looks like they sort of gave it a shot about a decade ago and haven't looked at it again since. It tries to recreate child windows as though the Mac had them, but allows them to be resized only from the lower-right corner (which macOS as a whole did... until 2011) and lets them be resized so small that the menu bar is no longer even fully drawn (which macOS has never done, on any window). I mean, hopefully that's a reflection of nobody actually still writing MDI applications, but it's a maintained sample provided in the current version of the SDK.
That plus the absence of various other ordinary OS window control features — I tried to reproduce the native 'constrain window contents to a certain aspect ratio' feature provided directly by NSWindow and ended up with a feedback loop responding to window resizes with more window resizes giving an inevitably jumpy mess — makes for very ill-fitting applications.
EDIT: that said, I sampled the XQuartz version of Inkscape probably about five years ago, and nothing can be as bad as that. There's a box in the lower right of the main window in which you can just type a zoom level, rather than trying to hit one manually. And under XQuartz it is sized just about large enough to fit one and a half digits. And this was a general pattern; anywhere I was allowed to type a measurement for exactness I wasn't allowed to see what I was typing.
That's basically the problem of every cross platform UI engine out there. They mimic the look of the host but neglect the actual workings.
A Qt application doesn't feel (or look if I'm being honest) like a native application on Windows anymore than it does on Mac. In fact, Qt couldn't be less native under the hood if it tried. They do everything themselves and only provide host native handles when they really have to.
The editor for the UI engine I wrote for a game back in the mid 90s basically did the same thing. Each game window when being edited appeared to be fully integrated into the Windows desktop. Which it basically did by just being a borderless/titlebarless window that I rendered everything into myself. Add in a bit of cunning to fool the OS into thinking my widgets were OS widgets, and the user could interact with it as if it were a real window. It was a pretty cool effect at the time. (If I do say so myself.) :)
Qt used to use the platform's theme engine to mimic the behaviour of widgets. Since Windows XP, Windows had a DLL for this purpose. This is what Java, Firefox and some other apps also did too through their respective GUI frameworks.
However these days Qt has deprecated the old-style widgets and now focuses on using QML. The UI is described by declarative layouts. The idea is render the scenegraph through surfaces and composition through OpenGL.
Porting some random application to Qt is typically non trivial by any stretch. It often doesn't stop at switching the UI since QT expects the UI to be hooked up with signals and slots to models and collections so you end up having to rewrite more and more code as QObjects to do that.
And for a graphically intensive application like Inkscape it probably entails a complete rewrite from scratch.
A port to QT for inkscape makes no sense to me. Inkscape is a graphics app itself. Not something that makes heavy use of a prebuilt ui toolkit.
I'm a fan of QT, in its place. Its almost its own language, as well as a ui toolkit. It would be a rewrite.
I see no benefit in porting an app that is 16 years stable.
Beware. It took Microsoft years to get collaborative edition working in a usable state, and don't get me started on live collaborative.
You are undoubtedly going to find that collaborative editing is an entirely different bag of trouble, and your 1.1 release will likely not contain it at all.
Unless it takes another 16 years, in which case, yeah, maybe.
This has been an interesting aspect of opensource. Some of the programmes I've tried ( and rejected) over the years have had this problem. Some aspect that is missing, unwieldy or broken, after several versions have come and gone. Or some crucial aspect has not ben user friendly because the ( mostly unpaid) volunteer devs aren't interested in sorting it out, don't understand why the users don't like it, can't understand why they find it difficult to use or simply "like it that way" and aren't interested in whether ordinary members of the public ( i.e. users) do.Or they just simply want to be working on the next bit of gee-whizzery.
(And before anyone gets all hot under the collar, yes I know Microsoft are pretty shit on this too - but mostly theirs are mammoth programmes spanning decades of development, with too many layers of management all vying for attention, and they aren't very good at either details or listening, which is a whole nuther ballgame)
Inkscape dev here. Your summise is somewhat correct, although it lacks some of the cause and effect inherent in the motivations of not just developers but all the support volunteers. For example, I'm a Free Software zealot, my whole bag is providing Free Desktops with a vector editor that's powerful, I don't care what Adobe is doing (except to pinch ideas) because Illustrator doesn't run on Linux. BUT other developers, some care about access for all users (support windows and mac because it's just that all users should have access) or care about features (they ARE cool to make).
But what I think is different and what we're trying to make different is how we do community. No matter how you are motivated to make Inkscape the thing better, the core consensus around the way in which the community is built is critical. Not having a difference between developer and non-developer contributors for example, inviting and mentoring anyone who wants to help in any role, even some of the boring ones like docs, or the gross ones like posting to facebook. Respect for contributors, patience for users and fair rules about where we should and shouldn't split out time between our pet desires and our shared responsibility borne from shared and growing relationships.
(We'll be doing a virtual hackfest to talk about features in 1.1 btw, should be fun to see all my friend's faces over that weekend)
No need to worry about Adobe, but with things like Affinity Designer costing only around $ 30, then anybody who is looking for this kind of program for professional work won't think twice about paying for it, if it does what it's supposed to do well or has one or two things that they really need. And this is fine. But it's also fine for some people to continue to use the Adobe suite if that's what suits them best.
Speaking for myself: I avoid the hassle of a Linux desktop by using MacOS, which has a good shell and all the necessary command line tools. I use a mixture of paid for and free software, depending largely on how I'm feeling when I need to do something, but also contribute to a couple of open source projects and I'm sure the same is true for a lot of people.
Simple example. Palemoon's devs have chosen not to indicate when a new add-on appears, unlike in FF and Thunderbird. It's been asked for and argued cogently and reasonably for in their forums by a number of individuals ( including me). There have been plenty of users indicating agreement. No one has posted any objection to this ( at least when I last checked).
The Dev team, however, say point blank that they won't do this because they want to be even handed and give all addons equal preference. We've argued that knowing that something new has become available isn't favouring it - it's letting us know about it, because otherwise..... we won't. Unless we have an idle couple of hours to search through all the categories (or maybe just the ones we might be interested in) for something we don't recognise.
So if you do develop something new for PM, no one will know.
And I for one am slowly drifting back to FF.
I've seen that motivation in volunteer coders described as "scratch one's own itch". And then share.
Indeed, the UX or documentation of much FOSS could be better, but at least opens ways to connect with the developers, something unheard of for most big box proprio software. Also, to participate.
A loss-loss is when people want it for free, AND will not even help a bit in making things better...
I find documentation is without fail better in Open Source projects.
Provided you can read code.
Many os projects follow gnu doc approach for text.
E.g. readme install authors etc. This approach is efficient for the document writer and effective for the reader. A quick entrypoint to the code is usually better that some fat computer manual you are not going to read.
Without Fail?
Try Libre Office release notes then.
They are in fact a "wiki" which even describes itself as a scratch pad. And is a complex tree of chronological changes, in jargon or technical names.. If there's a "What's changed in this version" section anywhere it's well hidden. And not what the "release notes" button takes you to.
It appears to be intended as a guide for someone as to what ought to go in some release notes.
i.e. The "Release notes" button in the programme and the link in the download page both take you to that wikki, which says;
This is an in-progress scratch-pad of notes to build release notes from as and when we release. Please do not list features that are to be shipped already in the 6.3 release! Please do not add wish-list features that you hope will be implemented, but only what actually is implemented already.
> This has been an interesting aspect of opensource.
It'd be more accurate to say, that's an interesting aspect of volunteer-powered projects.
I am not sure to what level there is a correlation between volunteer / opensource. I think a closer (inverse) correlation would be volunteer / project size.
Anyway, I'm surprised a project the size of Inkscape does not have contract devs. Seeing as a number of the core people are in France, I'd suggest getting in touch with Etalab.
I tried Inkscape many moons ago and could not get going with it - could not figure out how to do the simplest things. More recently I tried it again and was pleasantly surprised. It works great on Linux, but proved impossible to install on my MacBook. Therefore I'd be very happy with a proper Mac version.
Mac support is hugely important, thanks to the wide use of Macs in the artistic and designer community
Really? what is the logic behind someone paying the idiot tax, and then wanting free softwares?
My perception is that the one reason some people want a Mac at all is that they can access software that was specifically designed for it. BTW, Inkscape really benefits from having multiple mouse buttons.
Actually my preferred setup for heavy duty Inkscape production is a roller-ball with mouse buttons for the left hand and a mouse scroll wheel for the right. I've considered some hack to have the scroll wheel be run by my feet, but not implemented that yet.
Of couse Mac OS contains loads of free software.
My perception of Mac buyers is that they dont care too much if its foss or not, as long as Apple provide the spit and polish.
For Linux users it is important that it is free (as in speach)
For Windows users it seems it is important that that either someone paid for it or someone stole it.
BTW, Inkscape really benefits from having multiple mouse buttons.
Oh no, what will all the people who are still using Macs from the 1990s do? Still, good on you for avoiding "the idiot tax". That'll show Thatcher!
Stepping away from engaging with the platform warrior, I'm pretty optimistic for the new native port of Inkscape; another error that most half-hearted Linux ports make is acting as though only a discrete 1d scroll input is available and — top of the sins list — using that to control zoom level. Inkscape was always great to use in its native environment, I have a lot of faith in its developers.
some breaking changes in the new version, especially with extensions, most of which will need to be updated to work with this release.
A lot of my work used to depend on a rather abandoned extension for CNC.
Nice interacting with the developer, he suggested I send my donation not to him, but to an orphanage in his country.
I don't think that extension will ever be worked on again... If its functionality borked because of the new version, I'll have to be happy with my vintage version.
I used Xfig for years for making various engineering diagrams, that did not fall into the category of CAD. Inkscape can be use for this, but things that I found easy in Xfig are a bit clumsy in Inkscape. I suppose what I really want is Xfig with a Qt interface. I am not an artist, but I like a good clear layout, and I like a tool that will make it easy for me to get all my boxes lined up, rather than a bit off, which was always happening with Inkscape. There appears to be an odd attitude about when the attributes of a brush or pen are assigned, before drawing anything. To my mind, you select a brush size and a paint colour before putting paint to canvas, but Inkscape wants you to draw first, and set attributes later. A former engineer colleague of mine says that this behaviour was inherited from an early version of Illustrator. Xfig, for all its clunkiness, gets this right.
I still use Xfig quite a lot, largely because I'm very used to it. The results invariably are somewhat brutalist, but at least you can get things done quite easily. Sometime I even convert postscript graphs from e.g. scilab/python/R into fig format and re-do the labels in xfig; despite the many advantages they have over xfig, it is too much of a pain to get the axis furniture (ticks, labels, numbering) in a publishable state, and it's easier to edit or replace it. Also you can fix line widths and the like after the export.
Mind you, imo the best graphs are done using pgplot, so I may not be the most up-to-date judge :-)
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
