Smalltalk › Cincom › VisualWorks

GUI developpment

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

33 messages Options

Andre Schnoor

Re: GUI developpment

Sylvain Pralon wrote:
> Do you have some screenshots ?
See one attached below. Although this application uses a lot of custom
views, there are enough widgets visible demonstrating the general look
(right control panel with the nested tabs).

- Widgets kept simple, fast and generic
- Few shades of color only (blue, silver/gray, black)
- Ability to set a global color "hue" (e.g. silver, copper, gold)
- Scroolbars with zoom buttons (not yet 100% happy with their look)
- Optimized menus and font sizes on OSX
- Resizing splitter uses "grabber" look

Optimizations for "Wrapper" (which I'm not quite sure if they are
included with "Chimera" look)
- Window invalidation and redrawing approx. 100% faster with less flicker
- Tab controls use optimized refresh (no flicker, fast)
- Smoother and faster resizing splitter action
- Provision for real-time in-place graphics updates (no invalidation,
possible while scrolling)
- Enablement updates faster, less flicker

I haven't yet implemented the Mac menu bar (top of screen). The overall
design is accepted by our customers (Windows only, still can't sell
MacOSX products due to the slow 7.5 Aqua engine). I believe it's ok for
apps that don't require a native look (which is fortunately the case for
most multimedia products anyway).

Well, it *is* possible to create something moderately appealing,
although it really takes serious investments in "home brewn" UI
technology. I would say it is sufficient for a 1.0 release of something
really innovative and unique. But, if you're facing competition, it
probably gets tough. As I mentioned before, people mainly judge from the
surface and then decide, if it's worth the price. They simply can't
grasp the depth of a complex product and rather trust its appearance.

Andre

AppExample.gif (55K) Download Attachment

Andre Schnoor

Chimera Look (was: GUI developpment)

In reply to this post by Boris Popov, DeepCove Labs (SNN)

I've packaged and uploaded the Chimera Look & Feel for everybody to
test. Please give some feedback, if it works for you (or possibly not).
I don't have write access to the repository, so please resort to my
private web dump at http://www.neoscore.de (download zip at top of page).

Here's the package description:

This package implements the Look & Feel "Chimera". Chimera was designed
to provide a platform-neutral, minimalistic look, inspired by Swing and
AWT. The idea behind Chimera was to provide a consistent design on all
operating systems (Windows and OSX currently). The emulated native looks
are instantly recognized as being not the "real thing" - so why pretend?
A slick custom design has proven to be a viable solution for many
applications that can not deal with native widgets for whatever reason.

Chimera comes with some performance optimizations under the hood, most
notably faster and smoother window updates, especially for tab controls
and resizing splitters. It was tested for VisualWorks 7.4.1. Chimera has
no prerequisites and integrates with the VisualWorks L&F framework.
After loading the package, go to the VisualWorks settings panel and
select "Chimera Windows XP" for Windows and "Chimera MacOS X" for a Mac.
Although both versions run on either platform, font sizes and menus look
best on the designated machines.

"ChimeraLookPolicy initializeNewColors: #copper "
"ChimeraLookPolicy initializeNewColors: #silver "
"ChimeraLookPolicy initializeNewColors: #gold "
"ChimeraLookPolicy initializeNewColors: #platinum "

Chimera should work also on other platforms. The recommended way to
adopt Chimera for new platforms is to create a subclass of
ChimeraLookPolicy and ChimeraWidgetPolicy and fine-tune font sizes.
There is no need to fiddle with ChimeraFeelPolicy unless you want to do
serious hacks with custom keyboard behavior and the like.

Known Limitations:

Chimera works fine with all standard widgets and the UI builder,
although some customized views may show visual imperfections w.r.t
scrolling and background color (e.g. the RB hierarchy diagram). Resizing
splitters use a "handle" image, which requires some additional room.
This may not suit all current window layouts, where the splitters are
usually very thin. The Mac menu bar is not yet implemented. Comment out
the code in ApplicationModel>>postOpenWith: if you encounter problems
with the optimized window redrawing policy.

---
I've attached examples of the four color schemes "platinum", "gold",
"silver" and "copper" below.

Enjoy.

chimera_platinum.gif (11K) Download Attachment

chimera_copper.gif (11K) Download Attachment

chimera_silver.gif (11K) Download Attachment

chimera_gold.gif (11K) Download Attachment

Dennis smith-4

Re: Chimera Look

Thanks -- I look it -- I prefer the gold or copper.
A few tech comments
    1. there is one "self hello", which I assume is a method of yours in Object? I just removed the invocation
    2. PassiveController needs a dummy method "menuHolder: "
    3. changing colors gets a few errors -- I just gave up at that point, but the color's were
          nicely changed anyway. e.g. "Bad Marginss" error: in CompositionScanner, and
         a "Message not understood: #scalingFactor" message to the Transcript (100's of them).

Andre Schnoor wrote:

I've packaged and uploaded the Chimera Look & Feel for everybody to test. Please give some feedback, if it works for you (or possibly not). I don't have write access to the repository, so please resort to my private web dump at http://www.neoscore.de (download zip at top of page).

Here's the package description:

This package implements the Look & Feel "Chimera". Chimera was designed to provide a platform-neutral, minimalistic look, inspired by Swing and AWT. The idea behind Chimera was to provide a consistent design on all operating systems (Windows and OSX currently). The emulated native looks are instantly recognized as being not the "real thing" - so why pretend? A slick custom design has proven to be a viable solution for many applications that can not deal with native widgets for whatever reason.

Chimera comes with some performance optimizations under the hood, most notably faster and smoother window updates, especially for tab controls and resizing splitters. It was tested for VisualWorks 7.4.1. Chimera has no prerequisites and integrates with the VisualWorks L&F framework. After loading the package, go to the VisualWorks settings panel and select "Chimera Windows XP" for Windows and "Chimera MacOS X" for a Mac. Although both versions run on either platform, font sizes and menus look best on the designated machines.

   "ChimeraLookPolicy initializeNewColors: #copper "
   "ChimeraLookPolicy initializeNewColors: #silver "
   "ChimeraLookPolicy initializeNewColors: #gold "
   "ChimeraLookPolicy initializeNewColors: #platinum "

Chimera should work also on other platforms. The recommended way to adopt Chimera for new platforms is to create a subclass of ChimeraLookPolicy and ChimeraWidgetPolicy and fine-tune font sizes. There is no need to fiddle with ChimeraFeelPolicy unless you want to do serious hacks with custom keyboard behavior and the like.

Known Limitations:

Chimera works fine with all standard widgets and the UI builder, although some customized views may show visual imperfections w.r.t scrolling and background color (e.g. the RB hierarchy diagram). Resizing splitters use a "handle" image, which requires some additional room. This may not suit all current window layouts, where the splitters are usually very thin. The Mac menu bar is not yet implemented. Comment out the code in ApplicationModel>>postOpenWith: if you encounter problems with the optimized window redrawing policy.

---
I've attached examples of the four color schemes "platinum", "gold", "silver" and "copper" below.

Enjoy.

-- 
Dennis Smith                 		         +1 416.798.7948
Cherniak Software Development Corporation   Fax: +1 416.798.0948
509-2001 Sheppard Avenue East        [hidden email]
Toronto, ON M2J 4Z8              [hidden email]
Canada			         http://www.CherniakSoftware.com
Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP

Andre Schnoor

Re: Chimera Look

Thanks for the quick feedback. No doubt, it's never a good idea to publish the current development version ;-) You found some debugging code and missing dummies that are included in other packages.

I fixed the issues and updtaed the download file. It works flawlessly in a virgin 7.4.1 image on Windows. I'm going to check it with 7.5 on the Mac asap.

I could not reproduce those scaling errors. Looks like a font related problem. What OS and fonts are you using?

Andre

Dennis Smith wrote:

Thanks -- I look it -- I prefer the gold or copper.
A few tech comments
    1. there is one "self hello", which I assume is a method of yours in Object? I just removed the invocation
    2. PassiveController needs a dummy method "menuHolder: "
    3. changing colors gets a few errors -- I just gave up at that point, but the color's were
          nicely changed anyway. e.g. "Bad Marginss" error: in CompositionScanner, and
         a "Message not understood: #scalingFactor" message to the Transcript (100's of them).

Dennis smith-4

Re: Chimera Look

I had a few problems which seemed to be related to the use of TextAttributes instead of VariableSizeTextAttributes.
I replaced a couple of class references, reset the look and most things are fine now. Got rid of the
scalingFactor not understood and let my "print reports -- preview to screen" work, which got an exception before.

Andre Schnoor wrote:

Thanks for the quick feedback. No doubt, it's never a good idea to publish the current development version ;-) You found some debugging code and missing dummies that are included in other packages.

I fixed the issues and updtaed the download file. It works flawlessly in a virgin 7.4.1 image on Windows. I'm going to check it with 7.5 on the Mac asap.

I could not reproduce those scaling errors. Looks like a font related problem. What OS and fonts are you using?

Andre

Dennis Smith wrote:
Thanks -- I look it -- I prefer the gold or copper.
A few tech comments
    1. there is one "self hello", which I assume is a method of yours in Object? I just removed the invocation
    2. PassiveController needs a dummy method "menuHolder: "
    3. changing colors gets a few errors -- I just gave up at that point, but the color's were
          nicely changed anyway. e.g. "Bad Marginss" error: in CompositionScanner, and
         a "Message not understood: #scalingFactor" message to the Transcript (100's of them).

-- 
Dennis Smith                 		         +1 416.798.7948
Cherniak Software Development Corporation   Fax: +1 416.798.0948
509-2001 Sheppard Avenue East        [hidden email]
Toronto, ON M2J 4Z8              [hidden email]
Canada			         http://www.CherniakSoftware.com
Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP

Mark Pirogovsky-3

Re: Chimera Look

In reply to this post by Andre Schnoor

Hello All,

I just "Filed In" the parcel code into VW7.3.1 and it seem to work ok.
I had to "file in" as the parcel in the newer format.

The look is great, I like the how resizer looks a lot. I would
probably chose slightly different colors for the drop down menus though,
but it is more like personal preference.

--Mark

Andre Schnoor wrote:

> Thanks for the quick feedback. No doubt, it's never a good idea to
> publish the current development version ;-) You found some debugging
> code and missing dummies that are included in other packages.
>
> I fixed the issues and updtaed the download file. It works flawlessly in
> a virgin 7.4.1 image on Windows. I'm going to check it with 7.5 on the
> Mac asap.
>
> I could not reproduce those scaling errors. Looks like a font related
> problem. What OS and fonts are you using?
>
> Andre
>
> Dennis Smith wrote:
>
>> Thanks -- I look it -- I prefer the gold or copper.
>> A few tech comments
>> 1. there is one "self hello", which I assume is a method of yours
>> in Object? I just removed the invocation
>> 2. PassiveController needs a dummy method "menuHolder: "
>> 3. changing colors gets a few errors -- I just gave up at that
>> point, but the color's were
>> nicely changed anyway. e.g. "Bad Marginss" error: in
>> CompositionScanner, and
>> a "Message not understood: #scalingFactor" message to the
>> Transcript (100's of them).
>>
>
>

James Robertson-7

Re: Chimera Look

I've published the code to the public store repository; it worked
fine for me in 7.5, w/o any error messages to Transcript

At 09:44 AM 5/11/2007, you wrote:

>Hello All,
>
>I just "Filed In" the parcel code into VW7.3.1 and it seem to work
>ok. I had to "file in" as the parcel in the newer format.
>
>The look is great, I like the how resizer looks a lot. I would
>probably chose slightly different colors for the drop down menus
>though, but it is more like personal preference.
>
>
>--Mark
>
>Andre Schnoor wrote:
>>Thanks for the quick feedback. No doubt, it's never a good idea to
>>publish the current development version ;-) You found some
>>debugging code and missing dummies that are included in other packages.
>>I fixed the issues and updtaed the download file. It works
>>flawlessly in a virgin 7.4.1 image on Windows. I'm going to check
>>it with 7.5 on the Mac asap.
>>I could not reproduce those scaling errors. Looks like a font
>>related problem. What OS and fonts are you using?
>>Andre
>>Dennis Smith wrote:
>>
>>>Thanks -- I look it -- I prefer the gold or copper.
>>>A few tech comments
>>> 1. there is one "self hello", which I assume is a method of
>>> yours in Object? I just removed the invocation
>>> 2. PassiveController needs a dummy method "menuHolder: "
>>> 3. changing colors gets a few errors -- I just gave up at
>>> that point, but the color's were
>>> nicely changed anyway. e.g. "Bad Marginss" error: in
>>> CompositionScanner, and
>>> a "Message not understood: #scalingFactor" message to
>>> the Transcript (100's of them).

<Talk Small and Carry a Big Class Library>
James Robertson, Product Manager, Cincom Smalltalk
http://www.cincomsmalltalk.com/blog/blogView

Andre Schnoor

Re: Chimera Look

In reply to this post by Mark Pirogovsky-3

Mark Pirogovsky wrote:
> The look is great, I like the how resizer looks a lot. I would
> probably chose slightly different colors for the drop down menus
> though, but it is more like personal preference.

It is rather easy to customize the look to other color shades (see
below). They are derived from 3 gradients in hue, saturation and
brighness. The human eye is extremeny sensitive to hue changes, so the
looks may vary on different monitors and displays. What looks like
"gold" on one monitor may be "mud" on another ;-)

The (very subtle) impression of metal is not suported by reflections or
textures at all -- just the color gradients. That's why playing around
with the gradients can lead to weird experiences.

Also look at ChimeraWidgetPolicy class>>initializeDefaultMenuColors for
"patching" menu backgrounds. As long as only colors from the gradient
palette are used (this #standardBright, #standardMedium .... methods),
the look is kept consistent.

Andre

ChimeraWidgetPolicy class>>availableColorSets
"Color palette parameters for a various color flavors"
^Dictionary new
add: #silver -> (Array
with: (0.59 to: 0.59) "hue"
with: (0.08 to: 0.02) "saturation"
with: (0.4 to: 0.99)); "brightness"
add: #copper -> (Array
with: (0.081 to: 0.081)
with: (0.08 to: 0.02)
with: (0.23 to: 0.99));
add: #platinum -> (Array
with: (0.258 to: 0.258)
with: (0.08 to: 0.02)
with: (0.4 to: 0.99));
add: #gold -> (Array
with: (0.145 to: 0.145)
with: (0.08 to: 0.12)
with: (0.23 to: 0.99));
yourself

James Robertson-7

Re: Chimera Look

In reply to this post by James Robertson-7

Well, now that it's in Store, anyone can fix that kind of thing

At 10:14 AM 5/11/2007, you wrote:

>James Robertson wrote:
>>I've published the code to the public store repository; it worked
>>fine for me in 7.5, w/o any error messages to Transcript
>Most of the errors were related to the DefaultTextStyle being
>TextAttributes rather than Variable...
>I had code in my report-generator (preview mode to window) that
>assumed "Variable...", and some other
>places too.
>>
>>At 09:44 AM 5/11/2007, you wrote:
>>>Hello All,
>>>
>>>I just "Filed In" the parcel code into VW7.3.1 and it seem to work
>>>ok. I had to "file in" as the parcel in the newer format.
>>>
>>>The look is great, I like the how resizer looks a lot. I would
>>>probably chose slightly different colors for the drop down menus
>>>though, but it is more like personal preference.
>>>
>>>
>>>--Mark
>>>
>>>Andre Schnoor wrote:
>>>>Thanks for the quick feedback. No doubt, it's never a good idea
>>>>to publish the current development version ;-) You found some
>>>>debugging code and missing dummies that are included in other packages.
>>>>I fixed the issues and updtaed the download file. It works
>>>>flawlessly in a virgin 7.4.1 image on Windows. I'm going to check
>>>>it with 7.5 on the Mac asap.
>>>>I could not reproduce those scaling errors. Looks like a font
>>>>related problem. What OS and fonts are you using?
>>>>Andre
>>>>Dennis Smith wrote:
>>>>
>>>>>Thanks -- I look it -- I prefer the gold or copper.
>>>>>A few tech comments
>>>>> 1. there is one "self hello", which I assume is a method of
>>>>> yours in Object? I just removed the invocation
>>>>> 2. PassiveController needs a dummy method "menuHolder: "
>>>>> 3. changing colors gets a few errors -- I just gave up at
>>>>> that point, but the color's were
>>>>> nicely changed anyway. e.g. "Bad Marginss"
>>>>> error: in CompositionScanner, and
>>>>> a "Message not understood: #scalingFactor" message to
>>>>> the Transcript (100's of them).
>>
>><Talk Small and Carry a Big Class Library>
>>James Robertson, Product Manager, Cincom Smalltalk
>>http://www.cincomsmalltalk.com/blog/blogView
>
>--
>Dennis Smith +1 416.798.7948
>Cherniak Software Development Corporation Fax: +1 416.798.0948
>509-2001 Sheppard Avenue East [hidden email]
>Toronto, ON M2J 4Z8 sip:[hidden email]
>Canada http://www.CherniakSoftware.com
>Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP

<Talk Small and Carry a Big Class Library>
James Robertson, Product Manager, Cincom Smalltalk
http://www.cincomsmalltalk.com/blog/blogView

Steven Kelly

RE: Chimera Look (was: GUI developpment)

In reply to this post by Andre Schnoor

Andre,

Many thanks for making this available. It looks like there's a lot of
interest in it. In particular, we'd be interested in looking at it as a
possible default look for our app when it's on Linux, to replace the
ancient Motif. Cincom's Windows XP and Mac OS X are at least reasonable
attempts to mimic current looks on those platforms, but Motif looks odd
and bad to pretty much everyone. Being ugly and unergonomic doesn't help
either :-).

If you want to publish to the public repository, there are instructions
here on how to get and use the rights:
http://www.cincomsmalltalk.com/CincomSmalltalkWiki/PostgreSQL+Access+Pag
e
My experience is that people "behave themselves" when working with
others' packages - they generally don't make changes, but if they do
they are normally well-motivated and documented, or in a separate branch
if they guess the original author or wider community won't want them.
[Ah, I see Jim published it anyway, so my comments are rather after the
fact now!]

All the best,
Steve

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]]
> Sent: 11. toukokuuta 2007 13:24
> To: VWNC,
> Subject: Chimera Look (was: GUI developpment)
>
>
> I've packaged and uploaded the Chimera Look & Feel for everybody to
> test. Please give some feedback, if it works for you (or
> possibly not).
> I don't have write access to the repository, so please resort to my
> private web dump at http://www.neoscore.de (download zip at
> top of page).
>
> Here's the package description:
>
> This package implements the Look & Feel "Chimera". Chimera
> was designed
> to provide a platform-neutral, minimalistic look, inspired by
> Swing and
> AWT. The idea behind Chimera was to provide a consistent
> design on all
> operating systems (Windows and OSX currently). The emulated
> native looks
> are instantly recognized as being not the "real thing" - so
> why pretend?
> A slick custom design has proven to be a viable solution for many
> applications that can not deal with native widgets for
> whatever reason.
>
> Chimera comes with some performance optimizations under the
> hood, most
> notably faster and smoother window updates, especially for
> tab controls
> and resizing splitters. It was tested for VisualWorks 7.4.1.
> Chimera has
> no prerequisites and integrates with the VisualWorks L&F framework.
> After loading the package, go to the VisualWorks settings panel and
> select "Chimera Windows XP" for Windows and "Chimera MacOS X"
> for a Mac.
> Although both versions run on either platform, font sizes and
> menus look
> best on the designated machines.
>
> "ChimeraLookPolicy initializeNewColors: #copper "
> "ChimeraLookPolicy initializeNewColors: #silver "
> "ChimeraLookPolicy initializeNewColors: #gold "
> "ChimeraLookPolicy initializeNewColors: #platinum "
>
> Chimera should work also on other platforms. The recommended way to
> adopt Chimera for new platforms is to create a subclass of
> ChimeraLookPolicy and ChimeraWidgetPolicy and fine-tune font sizes.
> There is no need to fiddle with ChimeraFeelPolicy unless you
> want to do
> serious hacks with custom keyboard behavior and the like.
>
> Known Limitations:
>
> Chimera works fine with all standard widgets and the UI builder,
> although some customized views may show visual imperfections w.r.t
> scrolling and background color (e.g. the RB hierarchy
> diagram). Resizing
> splitters use a "handle" image, which requires some additional room.
> This may not suit all current window layouts, where the splitters are
> usually very thin. The Mac menu bar is not yet implemented.
> Comment out
> the code in ApplicationModel>>postOpenWith: if you encounter problems
> with the optimized window redrawing policy.
>
> ---
> I've attached examples of the four color schemes "platinum", "gold",
> "silver" and "copper" below.
>
> Enjoy.
>
>
>

Maarten Mostert-2

Re:Re: GUI developpment

In reply to this post by Travis Griggs-3

Hi Travis,

Does this mean that Cairo graphics are fully compatable with the classical MVC stuff ?

If I rewrite my interactive graphics would I see a significant speed benefit without loosing any of the build in capacities (image creating, printing etc) ?

What about long term cincom support ?

Rgrds,

@+Maarten,

Travis Griggs a écrit :

On May 10, 2007, at 2:08, Sylvain Pralon wrote:

In fact I want a more "sexy" interface with some cool objects.

I found that the default canvas API looks "oldy"

thanks,

If by "sexy" you mean appearance things like transforms, gradients, alpha painting modes, compositing, it doesn't really matter whether you use Widgetry or Wrapper. They're both based on the same drawing technology. In either technology your widget enters a displayOn: point with aGraphicsContext.

One way, would be to use the Cairo stuff to be able to do those kinds of sexy things. The "easy" way to do this, is something like:

displayOn: aGC

cr := aGC cairoContext.

"do cairo drawing stuff"

You can choose to do this using either VisualComponent objects (Wrapper) or Artist objects (Widgetry).

If by sexy you mean "moving things", then there are two pieces of code that may be of interest to you. One is the Animations package published in the OR by Michael Lucas-Smith, which is cool for doing fixed duration animations and is also Wrapper/Widgetry agnostic. For doing long running continuous Animating (i.e. open ended duration), you can use ExtraActivity which IS Wrapper specific, but could probably be made to work readily with Widgetry by changing a couple of methods and targets. The way events flow down is similar but different I believe.

And maybe what you want is both. You can use either/or. They don't conflict with each other.

--

Travis Griggs

Objologist

"It's [a spec] _the_ single worst way to write software, because it by definition means that the software was written to match theory, not reality" - Linus Torvalds

__________ Information NOD32 2184 (20070412) __________

Ce message a ete verifie par NOD32 Antivirus System.
http://www.nod32.com

Joachim Geidel

Re: GUI developpment

Hi Maarten,

Maarten Mostert schrieb am 12.05.2007 10:03:
> Does this mean that Cairo graphics are fully compatable with the
> classical MVC stuff ?

I guess that depends on what you mean by "fully compatible". ;-)
ComposedText for instance is not at all compatible with Cairo/Pango -
you'll have to rewrite text output in a way which does not use this
class. Also, you can't just take any VisualComponent and expect to be
able to render it on a CairoContext without rewriting its rendering
methods, i.e. writing a replacement for displayOn:.

> If I rewrite my interactive graphics would I see a significant speed
> benefit without loosing any of the build in capacities (image creating,
> printing etc) ?

Speed depends. I experimented a bit with an old version of Cairo and
found that drawing straight lines and rectangles was slower than the
VM's primitives (on Windows XP). However, I have not repeated the
measurements using the current version (1.4.0; 1.4.6 is out, but I am
not aware of a binary download yet, and I don't want to build it
myself). 1.4 should be much faster than 1.0/1.2, but I assume this
depends on the platform and the graphics operations which are used.

The biggest benefit will be in the quality of the graphics - just look
at the jagged graphics when drawing circles or lines - and the
additional features.

Joachim

Travis Griggs-3

Re: GUI developpment

On May 12, 2007, at 1:49, Joachim Geidel wrote:

Hi Maarten,

Maarten Mostert schrieb am 12.05.2007 10:03:

Does this mean that Cairo graphics are fully compatable with the
classical MVC stuff ?

I guess that depends on what you mean by "fully compatible". ;-)
ComposedText for instance is not at all compatible with Cairo/Pango -
you'll have to rewrite text output in a way which does not use this
class. Also, you can't just take any VisualComponent and expect to be
able to render it on a CairoContext without rewriting its rendering
methods, i.e. writing a replacement for displayOn:.

If I rewrite my interactive graphics would I see a significant speed
benefit without loosing any of the build in capacities (image creating,
printing etc) ?

Speed depends. I experimented a bit with an old version of Cairo and
found that drawing straight lines and rectangles was slower than the
VM's primitives (on Windows XP). However, I have not repeated the
measurements using the current version (1.4.0; 1.4.6 is out, but I am
not aware of a binary download yet, and I don't want to build it
myself). 1.4 should be much faster than 1.0/1.2, but I assume this
depends on the platform and the graphics operations which are used.

The biggest benefit will be in the quality of the graphics - just look
at the jagged graphics when drawing circles or lines - and the
additional features.

Joachim covers most of the points. I think Pango is a bit easier to use than what has evolved over the years w.r.t. text rendering. I'm sure there are some tradeoffs. But for the most part it's back to the good old BlueBook ST80 "Paragraph" object style interface.

I haven't measured "speed" either. The stuff I've written so far, has usually been fast enough. Any collection of algorithms has ways of being misused. What I find, is that it's an "Apples to Oranges" comparison. You just can't do graphics with classical X style GC interface of the same polish as you can with Cairo. OTOH, all that "glitz" comes at a price. Nothing's for free. I found, for example, when I did the Akamaru demo, which included live animation during dragging, the "Classical GC" display loop was a little faster. OTOH, both were fast enough were the fps looked smooth. So I didn't really care. And the Cairo one looked light years better.

You mentioned printing... I've not hooked up on printing stuff. As in direct to printers. You can always spew PDF/SVG files and then feed that to the printer. But using something like the Windows HDC for a printer, I've not tried yet. I imagine it might work.

Travis Griggs

Objologist

If you don't live on the bleeding edge, are you living as a dried wound?