Slashdot Mirror
Canvas 7 beta for Linux - now available
As the title says - Canvas 7 Beta is now available for downloading. This version was ported and compiled using WineLib. RPM, DEB, and TAR.GZ files available (which covers all Linux Distros). Could anyone grab it and post their impressions? These days it seems that the graphics programs market for Linux is heating up :)
Actually, I think this one is better:d efault.html
http://www.deneba.com/dazroot/prodinfo/canvas7/
and you forgot to mention the web design!
Check out Photogenics which is also out in beta. Story here.
[guess this gets moderated down automagically too as the one before, anyway ...]
>> Of course it's x86 only. After all, Canvas
>> (just as Corel's stuff) is based on WINE, with
>> all the drawbacks this sort of 'port' has.
>
> winelib is as portable as any other C code --
> it's the wine execution environment which
> requires x86, simply because those Windows
> applications were originally compiled for x86.
As someone else pointed out, Corel at least does in fact use WINE not winelib. I've not tried but I figure I could just plop the DLLs and EXEs into a windows installation and they might run.
Deneba may be in better shape with their approach with winelib (if it can be ported), I saw the bit about Canvas being a native Linux binary only later (and my download is still going).
> Think about it... just because someone uses
> winelib to port an application over from
> Windows, this doesn't exclude them from
> compiling winelib and their application to any
> $ARCH -- as long as they have the source for all
> of the application (portability issues aside).
True, it's possible. But I strongly doubt that Deneba did that (aside from the x86), or even intends to do that in future. Corel sure took the 'easy' way out from what I've seen. I don't expect to see any applications for another architecture from both of them.
I'll just continue to use MOL on LinuxPPC.
Michael
I curious about the programs that are like this one. Why do they do the way they do? I'm not understand. Surely they can be better. This good thing is not a joy.
Do we really this? Other programs around do this. Is really this any new thing?
It would be nice if Deneba would contribute code back to the WINE community, as Corel has. They appear to be using the Corel WINE branch - they're using the KDE theme that Corel developed, for example.
GraphViz is non interactive; instead you give feed it a text file containing a description of your (arbitrarily complex) graph and it spits out very nice output. I mean really nice. Check it out at the graphviz homepage.
About 6 months ago I used to use this program, but they wanted to charge me $20US for bug fix update on CD ROM. -- The program would NOT OPEN without it, but barfed and returned an error message. A program's not much use if you can't open it. (I THINK it was 3.0.3 to 3.0.5) I know this was way old, but they couldn't just email me an upgrade (not on the web site either) I called them but their support rep's hands were tied. I don't use Canvas any more. Didn't have time to screw around, so I standardized on something else. I just hope they will SUPPORT their products in the future. Good luck to everyone I guess......
Alright, hands up everyone who said "Cool!", downloaded it, then thought "What is it?"
I grabbed it. Seems pretty stable & full featured for a beta. Imports & exports many formats. It's really a vector drawing program so it competes w/ the likes of sketch very successfully. It also seems to have a lot of page layout capabilities.
To run it I had to run their 'wineserver' first & then run canvas7.
Also make sure you use 'unmanaged' windows.
I decided to compare the way they use winelib to the way Wordperfect Office uses winelib. I altered the wpolauncher script to use unmanaged windows. That gives the windows a Win95 look & feel but it makes the WPO applications significantly faster.
Then I noticed something: Wordperfect Office uses wine, not winelib!
Check this out:
[jthomas2@bob programs]$ file wpwin9.exe
wpwin9.exe: MS-DOS executable (EXE), OS/2 or MS Windows
and
[jthomas2@bob programs]$ file prwin9.exe
prwin9.exe: MS-DOS executable (EXE), OS/2 or MS Windows
Compare this to:
canvas7: ELF 32-bit LSB executable, Intel 80386, version 1, dynamically linked (uses shared libs), not stripped
That explains why some of those corel office applications, especially their presentation app run so slowly!
Someone from Corel want to explain this?
Perhaps they have done a good job, and it's just wonderful windows doing what it does best :)
Erik
Winelib. It's part of Wine. It's a library.
:^P
:^) (actually, you could throw some Spanish in there, if you like.)
If you want to split nosehairs, then The Gimp isn't "fully native" either, since it needs glib, gdk and gtk to run on X11R6 (native calls or nothing! Pure Xlib! I *like* to crash X!) Just because an app uses Winelib doesn't mean it's not native. I've not downloaded it yet (I'd like a nice QuarkXPress alternative on Linux, myself) but I'm willing to bet that it's an ELF executable. As you know, these don't work so well on Windows.
In other words...you got it wrong, I think, but it's hard to tell because of your extremely convoluted sentences. I'll be kind, since it seems that English is not your first language. To quote Bruce Willis from The Fifth Element, "I only speak two languages: English and bad English."
Stating on Slashdot that I like cheese since 1997.
GNUstep? (some OSX specific stuff is already there...)
Stating on Slashdot that I like cheese since 1997.
Blame the community for not giving a rip about making a binary standard.
:^(
I mean, who's expressing interest?
Not Linux/x86 folks. (Total World Domination...for better or for WORSE)
Not Linux/PPC folks (they just want native apps)
Not Linux/68k folks (I mean, Emacs works!)
Not Linux/Alpha folks (but it's fast as hell!)
Not Linux/StrongARM folks (uhhhhhh....)
Not Linux/S390 folks (didn't know about this one, BTW...thanks!)
nor any other platform I can think of right now. The goal seems to be, rather, to port the kernel to as many platforms as possible...and then to let the Stallmanites handle the folks who want commercial closed-source software ("Heretics! Who needs binary compatibility when all source should be FREE!")
What would a Linux VM hurt, anyway? I mean, there would be overhead, and there would be a slight performance hit compared to 100% native apps, but still, if an app used mostly system calls, this would be negligible. And if the VM used JIT techniques, this would be lessened.
I seem to remember that DEC had done some work on an x86 emulation layer for the Alpha, but I'm probably remembering wrong...I've never been lucky enough to be able to afford an Alpha for home.
Stating on Slashdot that I like cheese since 1997.
While the Linux community welcomes everyone who choses to use a Linux-kernel based system on any platform it's ported to, let's remember: the Linux kernel was orignally an x86 kernel. Period. It's primary intention was to be a freer-licensed replacement for the Minix kernel. Period. Linus Torvalds wanted an x86 kernel. Period. Other folks, rather than using BSD, decided to port the kernel to other platforms, without implementing (or even proposing) a binary-compatibility standard (and hey, many folks involved in these ports were in favor of GNU software...and with source available, who needs binary compatibiliy?)
Stating on Slashdot that I like cheese since 1997.
This is due to WineLib. Wine programs usually manage their own windows (to emulate the Windows behaviour at least WRT the API). I dunno about WineLib but it presumably defaults to the same.
Reality check guys: for the forseeable future, Windows will be the dominant platform. If WineLib is really getting good enough for vendors to port their software using it, then our chances of getting a load of the thousands of good Windows applications ported are greatly improved.
In fact, I could see the Windows API becoming a "commodity platform". That is, with the advent of Wine, we could be a approaching the point where Windows API programs will run in a lot of different places. Further, I can see Linux becoming a significant place to run Windows programs in the near future if Wine gets good enough.
I really think that anything that commoditizes the Win32 API is probably a good thing for the industry, even if we would all prefer native ports. The problem of Microsoft "extending" Win32 periodically would be greatly mitigated if this were the case.
--
-- Slashdot sucks.
I'd be interested in hearing your definition of 'real' native apps.
Using the Win32 API effectively isn't any different from using the GTK+ API except that there isn't a very good free Win32 API implementation yet.
Well, I agree it's better than /usr, but /usr/local is reserved for me to use (according to the FHS), and not for third party software to install into. It should install into /opt/canvas7.
That said, I personally have a shared /opt across all my boxen, so I've had to impose some structure on it. I'd want it installed in /opt/x86/linux/canvas7 (/opt/sparc/linux/canvas7 would be great, too, but I guess I'm being too optimistic there). Ideally, any RPMs should be relocatable to allow for setups like mine.
"The invisible and the non-existent look very much alike." -- Delos B. McKown
...100% CPU all the time. That can't be good. It also gives me a StarOffice(tm) feeling. I'd rather have a Qt or (gasp!)GTK+ version of this program. Even though it is native it still feels emulated.
No thanks...
"In short: just say NO TO DRUGS, and maybe you won't end up like the Hurd people." --Linus Torvalds
Of course it's x86 only. After all, Canvas (just as Corel's stuff) is based on WINE, with all the drawbacks this sort of 'port' has.
winelib is as portable as any other C code -- it's the wine execution environment which requires x86, simply because those Windows applications were originally compiled for x86. Think about it... just because someone uses winelib to port an application over from Windows, this doesn't exclude them from compiling winelib and their application to any $ARCH -- as long as they have the source for all of the application (portability issues aside).
| Who in their right mind would use windows
:)
... 1998.
| programs under WINE for actual work?
| There is no way you can reliably run programs
| like that
You might ask the same question about Windows iteself.
Anyway, depending on the application, you can quite reliably run Windows stuff under x86/Linux with wine. Back before I got leafnode set up, I used to run Agent like this. It simply didn't die on me - worked just like it did under Windows. Now Agent was always a pretty stable application - even under windows - but the point it that you *can* use Wine to get work done.
I've also been running Quicken 98 under WABI since
-- Rick
Wine does not work with XFree4.0, because of libpthread vs. Wine's own clone-based threading mechanism. See http://www.winehq.com for more details.
My take is that anything that uses Wine is bad for Unix, simply for the fact that it makes sure no vendor will ever actually develope real native applications for Unix.
* As is generally the case, my opinions do not reflect those of my employer.
Hmmm, that's strange. If Wine-based products are fully native according to your post, why does Paradox under WPO2000 insist on trying to create databases on "D:\". I don't know about you, but I don't have a directory structure under Linux that includes D:\.
* As is generally the case, my opinions do not reflect those of my employer.
Btw., has anybody noticed that Paradox in WPO2000 somehow thinks there is a "D:\" somewhere?
* As is generally the case, my opinions do not reflect those of my employer.
Gimp anyone?
And by the way, what is Gimp doing nowadays?
Back in the days of 1.1.9, they told us that Gimp 1.2 is coming. Now it's 1.1.19, and still nothing comes.
Hmmmm.... is this another example of the breakdown of open-source?
Muchas Gracias, Señor Edward Snowden !
Uhm, escuse me, but after a quick perusal of the Deneba site, I have to take task with the statement that all distros are covered. I know of some that aren't covered at all :
Yellow Dog Linux
LinuxPPC
MK Linux
Anything else for PowerPC users.
rats ! Kicked in the pants AGAIN by a x86-exclusivity clause...
Corel wanted to use WineLib (and is still planning to for future versions of WPO), but g++ is not yet suitable for general Windows porting. (precompiled headers being probably the largest problem - gcc doesn't have 'em, so large C++ projects take forever to build, as anyone who's compiled KDE knows all too well).
:)
;-)
The problem is exacerbated because Corel's stuff is all based on MFC, and MFC in turn is heavily tied to Visual C++. gcc 2.95.x helps this out by supporting anonymous structs and unions, but the pieces still aren't all in place to do seamless Winelib ports.
Deneba OTOH writes their code in pure C++ with no class libraries (Canvas evidentally can compile on both Windows and the MacOS from a common codebase). They began experimenting with WineLib the last week of December (based on their emails to wine-devel), so they've made excellent progress in a short amount of time. Kudos to them
Disclaimer: I don't work for either Corel or Deneba. Everything in this post was picked up or interpolated from wine-devel mailing list postings. If someone from those companies wants to correct me, please moderate them up
I visited Deneba's download page, and found unfortunately that there is not a PowerPC version available. Perhaps Deneba could contact the folks at LinuxPPC to obtain a box to develop on? Or is there a version in the works that they simply haven't come out with yet?
-Peter
...they DIDN'T have the intelligence to use a *different* path for their "special" version of wineserver.
/usr/local/bin and rename wineserver (the version that I built from the cvs pull last night) to newwineserver /usr/local/bin.
:-(
Evidence of this:
1) I installed canvas and started to run it.
2) 10 minutes later (after doing other things) I realized that canvas hadn't done anything..
3) I look in ps's output and notice that an instance of wineserver has zombie'd itself.
4) I kill the programs and try steps 2 and 3 several more times.
5) I go to
6) copy the version of wineserver that came with canvas to
7) Started canvas again and THIS time, it worked perfectly.
Problem: Now I need to swap wineserver every time I want to switch between canvas and any other program that I run using wine.
Next time, please have an option where I can explictly STATE a path for wineserver, if necessary.
GTK on Windows faster then on X ? That says something ... Great counter-argument to people claiming that X is generally as fast as not networked GUI implementations.
Mine just crashes with an exception c0000005, which if I remember my windows programming is the standard "there is no variable there" error. I have a newly-upgraded redhat 6.2, and xfree 4.0. any simliar probs?
It is only available for Linux on Pentium processors.
... shall I go on?
I *hate* it when people say "Available for Linux"
when they really mean Linux/x86.
It is not available for Linux/PPC or Linux/Alpha or Linux/S390 or
From looking at the WordPerfect Office 2000 reviews, WINE doesn't appear to be quite usable yet. Even with all the yacking over in that thread about "it's not Wine, it's WINE-LIB", the program still crashes and exhibits some odd and very un-Unixy behavior. So, even WineLib has its flaws.
The way that I see using WINE is similar to the way that I view using Delphi or C++ Builder to produce apps. They are all great tools for prototyping, and doing proof of concept type work. Wine is especially great for taking a native-Windows app and starting an open-source effort to port it to Windows. But I find this trend of commercial vendors doing a simple recompile with WineLib and calling it a Linux program disturbing, to say the least.
Linux is a platform for stability and reliability, and while Wine and Winelib are great to use to help in the porting process, no one should be releasing what should be polished commercial code using these tools, at this point.
It doesn't need to be ported to PPC in their minds, because most people that run LinuxPPC or another varient still have MacOS on those machines, and those that don't probably don't have a need for canvas.
Think About It ?
-0-0-0-0-0-0-0-0-0-
Laptop006
Melbourne, Australia
/* FUCK - The F-word is here so that you can grep for it */
Well, since it requires Wine, and Wine requires Windows DLL's (I believe), I think non-Intel folk are out of luck. Does anyone know if the real (non-beta) version will be native Xlib or GTK or Qt, i.e., non-Wine?
darren
Cthulhu for President!
(darren)
Has anyone deciphered this line? It sounds like this says, "We let your window manager do what it's supposed to do and don't try to interfere", which is what it should do, but I've never heard it phrased this way.
darren
Cthulhu for President!
(darren)
Oh the zealotry...
Lessee here. I use Paint Shop Pro for all my art, etc, and if I didn't like that, I could use good 'ol Photoshop. Where are those 2 apps for Linux? I wasn't impressed at all with the GIMP, or perhaps I just wasn't used to it.
I have used Canvas in the past under MacOS. It is an excellent program.
However, I wonder if there is any plan to compile for Linux/PPC? (or other CPUs...)
--Mark
Feature List.
Looks like this thing can do lots, Page Layout, Graphics, Photos, Web Pages, etc.
EC
"...we are moving toward a Web-centric stage and our dear PC will be one of
EverCode
A) Yes it is cheap stable and flexible, but it is certainly not fast, (with something like GNOME and GTK or KDE and Qt)
B) I doubt artists care about flexibility. They use a standard set of apps for many years at a time. Even a version upgrade is traumatic for most.
C) NT is not unstable, nor expensive. I can get a copy of NT Workstation for $200, (or $50 from training books) plus it stays up for a week at a time. NT may crash in server environments, but on the desktop it usually is well behaved. And it rarely crashed to the point where you don't have time to save your work. Macintosh just got true multitasking with OSX and has innards even more modern than Linux. (MACH and BSD) Especially with Mach and its good threading model, OSX looks like a powerhouse media OS. Then, of course, there is BeOS. Fast, stable, flexible (app scripting rocks all hell), free. For a lot of artistic tasks that can get by with ArtPaint or Easel (addmitadly not cream of crop apps, but they're decent) it rocks. Then there is the near future port of the GIMP and the port of the 3D modeler nendo and Maxon's 3D app. If Be keeps the momentum it has now (500,000 downloads over the course of a few days) it will be in the big leauges pretty soon.
A deep unwavering belief is a sure sign you're missing something...
Under your logic MacOSX is still newer than Linux. Linux is still very classical UNIXish. Yes, BSD is older, but the design underlying Mach is newer. The system Linux may be new, but they system MacOS X is newer. They design is based on straight UNIX, while Mach is a newer offshoot. Either way, MacOS X is more modern.
A deep unwavering belief is a sure sign you're missing something...
You must run the "register" program as root. With the standard Debian install, at least. From strace, it tries to open the canvas7 binary O_RDWR (read/write for those not versed in C), and the permission denied error is silently ignored.
You can read about it here:x /default.html
_ ____
http://www.deneba.com/dazroot/softlibs/cv7_linu
the feature list is rather long.
But basically, it's a bitmap/vector/publishing app for mac and windows and now linux!
_______________________________________________
Michael Cardenas
Lead Linux Programmer
Deneba Software http://www.deneba.com
hyperpoem.net
Since Canvas7 is a cross platform application, most of it is abstracted from the OS. In our testing, we found it to be relatively stable. But then again, it is our first beta.u lt.html
_ ____
We are hoping there there will be a good deal of feedback from the community to helping us make the app more stable. Towards that end, we've setup our own discussion forum for discussing issues with canvas for linux at:
http://www.deneba.com/dazroot/support/forumdefa
In our testing, we also found that a large number of the problems with Wine were rooted in window manager problems. To solve this we allow the user to select window manager settings according to the window manager they have. The user can also select an option to have the application operate without being managed by the window manager. This should eliminate a lot of the problems with stacking order that wpo has.
_______________________________________________
Michael Cardenas
Lead Linux Programmer
Deneba Software http://www.deneba.com
hyperpoem.net
Actually...
/.'ed ) the higher ups are going to decide what to do. And one possibility that has been discussed is a full native port. It all depends on the interest of the community, and the _company's_ ability to regain it's investment. Developers, boxes, cd's, artists, time, and bandwidth all cost money.
_ ____
Depending on the response to this release (and the response has obviously been great, we're totally
_So_ winelib has given us an entry door, to allow us to get into the market and feel it out. Anything that gets more software companies into the linux market has to be a good thing for linux right? Software companies have people who have 8 hours+ a day to spend making kick ass products. Be it on linux, or on any other platform that has the potential to give a good return on investment.
_______________________________________________
Michael Cardenas
Lead Linux Programmer
Deneba Software http://www.deneba.com
hyperpoem.net
If someone would like to help us distribute Canvas for linux by providing a mirror, please contact mbc@deneba.com
_ ____
Thanks!
_______________________________________________
Michael Cardenas
Lead Linux Programmer
Deneba Software http://www.deneba.com
hyperpoem.net
Wine does not *require* windows DLLs. It can load them for their native architecture (intel) if the application requires it. It also implements the windows API itself. Basically, if the program requires an external DLL, wine will load it. If it sticks to plain API calls (or the windows dlls the wine people have finished porting) it runs natively.
Since they're calling it a native version, I bet it's the latter.
Tetris rules.
Late me start out saying that this is great news. I use a Macintosh with LinuxPPC on one drive and MacOS on another. It is the very fact that I have to be in MacOS to use Canvas that keeps me from using LinuxPPC as my default system.
I heavily rely on Canvas for techinical illustrations in my research documents. I draw them in Canvas (6 -- haven't bothered to upgrade to 7 yet), convert them to EPS, and include them in my LaTeX documents. I can draw the graph of a complex 20 state finite automata in 5 minutes with this program. For what I do (your results may vary), there is simply nothing like this program currently available for Linux.
GIMP is a wonderful program, but you must understand what its purpose is. GIMP is an image manipulation program. It is meant to be a freeware replacement to Photoshop. It is for manipulating bitmapped images (Of high resolution) and performing cool effects on them.
Canvas, on the other hand, got its start as a technical illustration tool. Sort of like a poor man's CAD. In many ways it is closer to xfig, though its interface is far superior. All objects are represented as vectors unless they are draw within a image box (A bitmap object). This gives Canvas several features that GIMP is sorely (At least in the stuff that I do) lacking.
Geometric objects (Circles, rectangles, beziers) in Canvas are not bitmapped and hence can be rescaled on the fly with no jaggies or need for antialiasing.
While I am sure Slashdotters will correct me, I believe that object placement in GIMP is visual. You cannot select an object and type in a coordinate for it to move to. You can do this in Canvas relative to your current measurement unit (Points, centimeter, inches, whatever). This allows you to align objects so they will print correctly, as screen resolution is simply not good enough for press.
Text support in GIMP is just too primitive; this is my primary complaint with this program. In Canvas, text remains text. You can always reedit the text after you have bent it around a line, filled it with a gradient, rotated it 234.5 degrees, or whatever. And when you export the image to PDF, the text is still editable there. This is particularly important to me as various publications have different font requirements and I do not want to have to redraw my pictures.
With Canvas 5, Deneba extended their product from a technical illustration to tool to an All-In-One tool. It now can do a lot of what Photoshop does, and hence does compete directly with GIMP in that regard.
As far as I know, Canvas can now do everything that GIMP does. As to how well it does all this (compared to GIMP, Photoshop, or whatever), I cannot tell you that. I just do technical illustrations, not image manipulation.
-Walker
Interesting how this appeared the day after I received my beta copy of Corel Draw 9 for Linux...
to make it accessible for redhat, debian and suse... tar.gz files cover all distributions just fine. :)
-- http://www.cerastes.org
I assume "all Linux distros" to mean x86 only. Or am I just pessimistic?
Are you on $1 crack or trolling?
;-)
Linux is a great platform for artists. It's cheap, allows for flexiblity, it's fast, and very stable. Art is another form of hacking
NT? Fugettaboutit! Too unstable and expensive. 98? Why?! Macintosh? Does not support true mulitasking.
For now Linux looks like the most promising choice for starving artists.
Keep those graphic apps comming!
If design is not Bauhaus, it is Baroque.
GIMP really isn't fast. I really like using it, but as soon as I get outside of the 640x480 website-graphics scope, it becomes too slow to be managable. I've tried several times to use gimp to create simple CDROM covers at 300 dpi, and kept being surprised by it ending up more sluggish than what I remember from Photoshop on the computers of three years ago.
I've upgraded to the latest developer releases to see if in this field there is any improvement. There is a little, but there's, in my opinion, still miles to go before it will be feasible for high-resolution print graphics. I think they should consider focusing on using a method where you can do gimp operations on a low-resolution preview-image to later repeat those operations scriptomatically on the full res copy.
Pi
On the Interface Usability plane, GIMP is actually really getting there. Especially with the 1.1 releases, there is little functionality not in Gimp that is in the packages you mentioned.
This is not saying that there aren't still fields where Gimp has a long way to go. Also, mimicking what's already out there is not always the best idea. I was always pissed off by the fact that there was no simple way to create lines and outline boxes in Photoshop (select box, fill with color, shrink border one pixel, delete selection, yuck). I'm sort of disappointed Gimp lacks this too.
You know what's really missing? And not only on Linux, but also on Mac, Windows, BeOS, OS/2 and all those other platforms (excluding Amiga)? Something to replace DeluxePaint, which was and still is one of the most useful programs for on-screen pixel art (which currently is the focus of Gimp to begin with) available. Someone dig Dan Silva out of his coffin!
Pi
Both Gtk and Motif are highly customizable. You'd be surprised how much better Motif apps can look if you mess around a bit with the resources, stopping it from thinking the menu font should be 18pts and buttons should be the size of Mount Everest. The same is true for Gtk, check out documentation on gtkrc.
The thing I dislike about Gtk is the API itself, which is the reason I use FLTK, which also helps keeping the tabs on memory overhead a bit better than the two mainstream linux toolkits at this time.
Pi
As mentioned in oodles of posts above this one, WPO2000 uses WINE, not winelib.
HTH. HAND.Pi
That's a bad indication. Not adequately handling error-returns from library calls is a really bad habit, which gives me a bad feeling about the overall robustness of the app.
Pi
I can't get the registration program to work at all - whitespace or not. Anyone got any ideas about how to get this sorted out?
FYI, Mach and BSD predate Linux by a looooong time...
-W.W.
"Well it should be obvious to even the most dim-witted individual who holds an advanced degree in hyperbolic topology...
I'm sick and tired of having to see virtually all application programs for Linux be packaged for installation in /usr as opposed to /usr/local or /opt. Most of them are not relocatable so that unless I can get my hands on source rpm (equivalents for deb), I can't get them installed in /usr/local or /opt. Therefore, I'm very glad to find Deneba packaged Canvas7 beta for Linux to be installed in /usr/local. Every application should follow Deneba in this respect unless they think of their programs as essential parts of Linux OS.
Canvas 7 Linux Edition is a fully native Linux application
Until here I thought "huh? Oh, well, off course. Fun."
which was developed with the help of the Wine library. For more information on wine you can go to
^_^ Now things get clear. They have ported it with the help of Wine. Good to see that Wine is of use here. But a funny sidenote is that I have never seen anyone mention to be "fully native" when he really is so, but that it often happens to make sure that he is when he actually is not. Of course all they tried to say is that you don't need Wine to run Canvas.
Anyway, if you would need it, you wouldn't get there ;-)
Now where are the screenshots for Linux??
It's... It's...
"We can confirm that Debian does *not* ship the version with the trojan horse. Our version predates it." [CA-2002-28]
Creating lines - see my tutorial Creating outline boxes should be - Select Box, Edit/Stroke. Seth
With Corel Office, IBM Toppage and now this using Winelib I guess that winelib has reached a level where it is usable. While it is great to have more apps for Linux, I am not sure if it is a good thing is if all we get are windows recompiles instead of real ports using the Linux native widget set Gtk. Guess time will tell if this was a great way to get linux rolling onto the desktop, or just something that made people think that Linux, like OS/2, didn't have any apps of its own, and thereby was of little interest.
Yes, its a cruel man indeed who slashdots an NT server oughtabe a crime to do that
I downloaded the RPM and installed on a RH6.0 machine. The registration utility has a bug in it (whitespace in responses seems to be interpreted as \n's). After figuring out the bug, I got the software enabled. It was *remarkably* slow. And it was unable to load Canvas5.2 files from disk. At that point I lost interest. It doesn't make sense to me to rush a product to 'market' if its early introduction is just going to irritate potential users. (But I am glad Deneba is working on it.)
What's with all these graphics packages on Linux suddenly? Are we looking at a trend here? I'm mean, surely Linux "hackers" aren't so artistic, is it possible that Linux *is* a viable platform for anything else but hacking? :)
Bad jokes aside, I think this is a sign of times to come. I bet you that before the year end you'll have a choice of applications ported for Linux that more and more of the non-technically minded companies (media, art, etc.) will be "going Linux".
Maybe things aren't so bleak for RedHat et al after all. hey, if nothing, VA Linux will now be selling much more computers so maybe they'll cough up some dough for *real* reporters