(forw) [Uml-devel] (no subject)

Sat May 10 00:25:02 UTC 2003

A really broken mail, hope someone is able to read this. Or was this mail
allready send to the list?

Steinchen

----- Forwarded message from "rwlbuis at xs4all.nl" <rwlbuis at xs4all.nl> -----

Sender: umbrello-devel-admin at kde.org
From: "rwlbuis at xs4all.nl" <rwlbuis at xs4all.nl>
Subject: [Uml-devel] (no subject)
Date: Wed, 07 May 2003 11:18:04 -0700
To: koffice-devel at mail.kde.org,  rwlbuis at xs4all.nl,  
Reply-To: rwlbuis at xs4all.nl

dirk.schoenberger at sz-online.de,
     umbrello-devel at kde.org 
Subject: Re: karbon/umbrello
Date: Wed, 7 May 2003 14:18:50 -0400
MIME-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Return-Path: rwlbuis at xs4all.nl
X-OriginalArrivalTime: 07 May 2003 18:23:17.0687 (UTC) FILETIME=[BB1D2C70:01C314C5]

Hi again, =0A =0A>so it sounds like there's a need for a general purpose v=
ector drawing  =0A>framework that works with some kind of painter=2E this =
could be used for,
say,  =0A>umbrello, kivio, karbon or just about anything that needs to dis=
play
create  =0A>and display vector graphics=2E excellent=2E =0A =0AIt basicall=
y boils down to that :) =0A =0A>i really like the V* object hierarchy=2E=2E=
=2E it certainly seems like the right
=0A>direction=2E even more, i also i like the usage of base objects as
interfaces  =0A =0AKeep in mind though that not every class that starts wi=
th a V will be
appropriate =0Aoutside karbon ;) For instance we have vselection which may=
 be useless
outside =0Akarbon, and vfillrule=2Eh, which may be overkill on its own and=
 could be
moved to =0Akpainter perhaps=2E =0AAnother unclear area are things like VG=
radient, VPattern=2E The unclear thing
atm =0Ais whether such a thing should be in shared lib, kpainter or both=2E=
=2E=2E =0A =0A>for managing certain components of objects=2E unless i'm co=
mpletely  =0A>misinterpreting the code, i see a potential problem involvin=
g multiple  =0A>inheritance - granted, it can be eliminated via virtual in=
heritance=2E the  =0A>other thing might be to introduce QObject as a base =
of VObject - i know
its a  =0A>little heavy, but it does grant signal/slot capabilities to obj=
ects in the
=0A>canvas=2E =0A =0AI dont see the MI problem? Probably I am overlooking =
something, you may =0Areuse the classes in another way I imagined or so=2E=
=2E=2E =0A =0A>there are some KOffice refactoring issues - like eliminatin=
g any
dependencies  =0A>on KOffice=2E not that KO is bad, its probably just a li=
ttle heavy for
smaller  =0A =0AWell IIRC Lenny wanted to make a core path lib not limited=
 to karbon=2E So
that would =0Aprobably imply not using things like KoRect and other koffic=
e structures=2E =0A =0A>applications to link against and it would be nice =
to have this as stand
alone  =0A>as possible=2E for this, i think KPainter would be an excellent=
 replacement
for  =0A>VKoPainter - they're basically the same thing anyway (built on to=
p of  =0A>libart)=2E we might even be able to package KPainter as the defa=
ult painter
for  =0A =0AThey are close, but with a slightly different philosophy=2E KP=
ainter tries to
stick =0Ato QPainter/QPaintDevice abstraction (so KPainter and QPainter sh=
ould be =0Ainterchangeable), whereas VKoPainter was just something I hacke=
d up
quickly=2E =0A =0A>the object hierarchy - that means there wouldn't need t=
o be any massive  =0A>rewriting for karbon (that i can forsee)=2E =0A =0AP=
hew :) =0A =0A>the canvas is probably going to be a little harder=2E i thi=
nk it might be  =0A>worthwhile to try and provide an abstract canvas inter=
face and then
provide a  =0A>default implementation as with KPainter/VPainter stuff i su=
ggested=2E the
same  =0A>should go for VDocument=2E that provides a lot of interesting op=
portunities
for  =0A>people down the road, should the need arise=2E =0A =0ARight=2E I =
have no idea yet how common VDocument can be for the three apps=2E=2E=2E =0A=
BTW load/save as it is now could have some implications=2E ATM for instanc=
e =0Akarbon VComposite saves/loads svg path data=2E In general for karbon =
the file
format =0Ahas gone into the direction of OO Draw=2E Please have a think ho=
w applicable
this is =0Ato umbrello, and whether there are opportunities for extending =
the format=2E
OTOH =0Ayou can derive and implement your own load/save routines, but that=
 would be
a slight =0Awaste of code=2E =0A =0A>question: if people are serious about=
 proceeding with this, where does it
go?  =0A>i'd suggest KPainter, but the name might be a little misleading b=
ecause
we'd  =0A>be providing alot more than just KPainter (and alot less than Ka=
rbon :)=2E  =0A>actually, what would be a good name for this thing? =0A =0A=
KPainter should be restricted to painting :) I am not very good at coming
up with =0Anames, but vector should probably be in it :) =0A =0A>anyway, d=
epending on what my advisor needs me to do for research this
summer  =0A>(hopefully not too much), i'm going to have tons of free time =
starting
next  =0A>week=2E being that i'd love to see this get used for umbrello2 i=
 suppose
i'll  =0A>have to do some work getting stuff started=2E=2E=2E this should =
be fun :) =0A =0AI really hope you have lots of time=2E Ofcourse I am inte=
rested a lot in this
stuff and =0Awilling to help as much as time permits=2E =0ACheers, =0A =0A=
Rob=2E=20

--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web=2Ecom/ =2E

-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

_______________________________________________
Uml-devel mailing list
umbrello-devel at kde.org
https://mail.kde.org/mailman/listinfo/umbrello-devel

----- End forwarded message -----

-- 
http://www.hpfsc.de/ - die Seite rund um:
Assembler, Bundeswehr, TFT LCDs, Halle/Saale, Fahrradtouren,
Wanderstaat Mauma, Raumschiff USS Nathan, Enemy Room, MLCAD Tutorial