Menu
▾
▴
netron-development — Netron development list
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(4) |
Dec
(6) |
|---|
|
From: Mark J. <mj...@we...> - 2005-12-14 17:16:51
|
After building the changes needed for the Font support, I created a copy in 'Netron_F11'. Despite all efforts from CVS, this seems to work properly (at least it compiles). It would be a good idea to check this Version out and to test it. Mark Johnson, Berlin Germany mj...@mj... |
|
From: Mark J. <mj...@we...> - 2005-12-13 20:02:02
|
This is a ,Global' Concept. What you do afterwards with the Shapes/Connections is up to you. - Goal 1 is to set the desired Font at the start of an Application. - Goal 2 is that the User can set everything when desired. At the moment the concept is that all Shapes use the same Font. The changing the Property of the Entity.Font will decide how far this can be allowed - inside the Class (as it is now) [private] - inside the Dll (this suggestion) [internal] - inside a derived Class [protected] - outside the class (the best solution) [public] For a specific Shape / Connection the override Property of Font can be used to prevent Font : - Name - Size - Style to be changed. - this should be possible (and desirable) The final Goal should be the balance of - the User having the freedom to decide which Font (Name, Size and Style) should be used - the Developer having the freedom to determine that certain Properties must be retained o WHEN this is really needed (for whatever reason) In my opinion (short before the 'one beer to many'): Font should be 'public' - so that the User see it the way he wants it - the developer can (when really needed) prevent what is not desired Using a Public Property in the Shape/Connector gives the developer everything he needs. As it is now (Protected) the User can do nothing. Mark Johnson, Berlin Germany mj...@mj... |
|
From: Martin C. <mar...@ei...> - 2005-12-13 17:04:36
|
Hi Mark,
This would certainly be a useful addition. Does this approach allow you
to have a different font for Connections versus Shapes. Also it can be
useful to allow different shapes to use a different font. Your approach
certainly looks like a very good starting point.
Just my 2 cent.
Regards,
Martin
Mark Johnson wrote:
> * *
>
> * In the past, there were discutions about a Global Font support.*
>
> * *
>
> * Last March, when I was doing a Praticum where I hoped to get a
> permanent Job,*
>
> * I showed this Library ro the owner and the first question was 'can it
> Zoom, change the Colours and Font'?*
>
> * *
>
> * Building in the proper Zooming and Colouring was not a problem, but
> the Font was.*
>
> * *
>
> * Last month François and I again has a talk about this and came to no
> conclusion.*
>
> * *
>
> * Yesterday, however (still having no Job), while preparing my Shape
> Demo to work within the MDI-Application,*
>
> * I realized that the logic I used there would also solve the Problem
> here.*
>
> * *
>
> * The the main pain there was the commenly used Objects/Methods had to
> be passed to each Frame*
>
> * apon creation.*
>
> * *
>
> * I then tried creating a Class in the Dll that stored Static Fields
> which were filled upon*
>
> * Application start (Main-Form, MainMenu, StatusBar, Colours, Font,
> Project Paths etc) and*
>
> * simply read out by the Forms that used the same Dll.*
>
> * *
>
> * Calling an Application twice from the same /Bin using also the same
> Dll (also in the same /Bin)*
>
> * created an Unique Version of the Static Class for each Application -
> which meant that the*
>
> * first copy could change a static Field (in this case the Font) but
> this would not effect*
>
> * the Value in the second Application (i.e. the Second Application
> would not use the Font*
>
> * set by the first Application).*
>
> * *
>
> * The problem here is that when a Shape is created it uses the default
> Font set in Entity.cs.*
>
> * This could not be changed in a way that after a certin Point another
> Font should be used.*
>
> * *
>
> * Since Entity.Font was 'protected', it could also not be changed
> afterwards.*
>
> * *
>
> * My suggestion is the following :*
>
> * *
>
> * - one small Class in 'Netron.GraphLib' with static Fields*
>
> * - Font*
>
> * - and maybe others like CutureInfo for language support.*
>
> * *
>
> * - When the Application calls the Dll for the first the Default value
> will be set*
>
> * - for CutureInfo this would be that of the Machine called on.*
>
> * The Application could then change the default Values :*
>
> * - 'NetronBase.Font = WinForm.Font; '*
>
> * *
>
> * With Entity.InitEntity() changed to : *
>
> * *
>
> * // mFont = new
> Font(mFontFamily,mFontSize,FontStyle.Regular,GraphicsUnit.Point);*
>
> * Font = NetronBase.Font;*
>
> * *
>
> * all Shapes / Connection etc. would use the desired Font.*
>
> * *
>
> * If Entity.Font was changed from 'protected' to 'internal'*
>
> * *
>
> * internal Font Font*
>
> * {*
>
> * get{return this.mFont;}*
>
> * set*
>
> * {*
>
> * this.mFont = value;*
>
> * this.mFontFamily = value.FontFamily.ToString();*
>
> * this.mFontSize = value.Size; *
>
> * RecalculateSize = true;*
>
> * this.Invalidate();*
>
> * }*
>
> * }*
>
> * - note added 'RecalculateSize = true;' !*
>
> * *
>
> * a Propery in the GraphControl for 'Font' could be written*
>
> * that could change the Font used at any time (i.e. Object allready
> created) :*
>
> * *
>
> * [Category("Graph"), Browsable(true), Description("Gets or sets the
> Font for the GraphControl and all Shapes and Connectors.")]*
>
> * public override Font Font*
>
> * {*
>
> * get*
>
> * {*
>
> * return base.Font;*
>
> * }*
>
> * set*
>
> * {*
>
> * if (value != null)*
>
> * {*
>
> * base.Font = value;*
>
> * NetronBase.Font = base.Font;*
>
> * foreach(Shape so in mAbstract.Shapes)*
>
> * {*
>
> * so.Font = base.Font;*
>
> * foreach(Connector co in so.Connectors)*
>
> * {*
>
> * co.Font = base.Font;*
>
> * foreach (Connection con in co.Connections)*
>
> * **{*
>
> * con.Font = base.Font;*
>
> * } // foreach (Connection con in co.Connections)*
>
> * } // foreach(Connector co in so.Connectors)*
>
> * } // foreach(Shape so in mAbstract.Shapes)*
>
> * // Will force all Controls to Paint with new Font*
>
> * Invalidate();*
>
> * } // if (value != null)*
>
> * } // Set*
>
> * } // public override Font Font*
>
> * *
>
> * With these changes, every thing works well with me after insuring that
> NetronGraphControl*
>
> * uses the Parent.Font when recalulating it size.*
>
> * *
>
> * All Shapes would have to be Font aware, but most are.*
>
> * And if not, they should be changed.*
>
> * *
>
> * If there are no objections to this I would like to commit the needed
> changes to CVS.*
>
> * *
>
> * **Mark Johnson, Berlin Germany *
>
> * mj...@mj... <mailto:mj...@mj...>*
>
> * *
>
> *PS : I wish Windows would do the same, I allways hate changing to the
> Fornt that I use 99,9999 % of the time … *
>
> * *
>
> * *
>
>
> ------------------------------------------------------------------------
>
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.371 / Virus Database: 267.13.13/198 - Release Date: 12/12/2005
>
|
|
From: Mark J. <mj...@we...> - 2005-12-13 14:04:11
|
=20
In the past, there were discutions about a Global Font support.
=20
Last March, when I was doing a Praticum where I hoped to get a =
permanent
Job,
I showed this Library ro the owner and the first question was 'can it
Zoom, change the Colours and Font'?
=20
Building in the proper Zooming and Colouring was not a problem, but the
Font was.
=20
Last month Fran=E7ois and I again has a talk about this and came to no
conclusion.
=20
Yesterday, however (still having no Job), while preparing my Shape Demo =
to
work within the MDI-Application,
I realized that the logic I used there would also solve the Problem =
here.
=20
The the main pain there was the commenly used Objects/Methods had to be
passed to each Frame
apon creation.
=20
I then tried creating a Class in the Dll that stored Static Fields =
which
were filled upon
Application start (Main-Form, MainMenu, StatusBar, Colours, Font, =
Project
Paths etc) and
simply read out by the Forms that used the same Dll.
=20
Calling an Application twice from the same /Bin using also the same Dll
(also in the same /Bin)
created an Unique Version of the Static Class for each Application - =
which
meant that the
first copy could change a static Field (in this case the Font) but =
this
would not effect
the Value in the second Application (i.e. the Second Application would =
not
use the Font
set by the first Application).
=20
The problem here is that when a Shape is created it uses the default =
Font
set in Entity.cs.
This could not be changed in a way that after a certin Point another =
Font
should be used.
=20
Since Entity.Font was 'protected', it could also not be changed
afterwards.
=20
My suggestion is the following :
=20
- one small Class in 'Netron.GraphLib' with static Fields
- Font
- and maybe others like CutureInfo for language support.
=20
- When the Application calls the Dll for the first the Default value =
will
be set
- for CutureInfo this would be that of the Machine called on.
The Application could then change the default Values :
- 'NetronBase.Font =3D WinForm.Font; '
=20
With Entity.InitEntity() changed to :=20
=20
// mFont =3D new
Font(mFontFamily,mFontSize,FontStyle.Regular,GraphicsUnit.Point);
Font =3D NetronBase.Font;
=20
all Shapes / Connection etc. would use the desired Font.
=20
If Entity.Font was changed from 'protected' to 'internal'
=20
internal Font Font
{
get{return this.mFont;}
set
{
this.mFont =3D value;
this.mFontFamily =3D value.FontFamily.ToString();
this.mFontSize =3D value.Size; =20
RecalculateSize =3D true;
this.Invalidate();
}
}
- note added 'RecalculateSize =3D true;' !
=20
a Propery in the GraphControl for 'Font' could be written
that could change the Font used at any time (i.e. Object allready
created) :
=20
[Category("Graph"), Browsable(true), Description("Gets or sets the =
Font
for the GraphControl and all Shapes and Connectors.")]
public override Font Font
{
get
{
return base.Font;
}
set
{
if (value !=3D null)
{
base.Font =3D value;
NetronBase.Font =3D base.Font;
foreach(Shape so in mAbstract.Shapes)
{
so.Font =3D base.Font;
foreach(Connector co in so.Connectors)
{
co.Font =3D base.Font;
foreach (Connection con in co.Connections)
{
con.Font =3D base.Font;
} // foreach (Connection con in co.Connections)
} // foreach(Connector co in so.Connectors)
} // foreach(Shape so in mAbstract.Shapes)
// Will force all Controls to Paint with new Font
Invalidate();
} // if (value !=3D null)
} // Set
} // public override Font Font
=20
With these changes, every thing works well with me after insuring that
NetronGraphControl
uses the Parent.Font when recalulating it size.
=20
All Shapes would have to be Font aware, but most are.
And if not, they should be changed.
=20
If there are no objections to this I would like to commit the needed
changes to CVS.
=20
Mark Johnson, Berlin Germany=20
mj...@mj...
=20
PS : I wish Windows would do the same, I allways hate changing to the =
Fornt
that I use 99,9999 % of the time =85=20
=20
=20
|
|
From: Martin C. <mar...@ei...> - 2005-12-08 14:34:37
|
Hi Mark, I checked out the latest code last week and so far have had no issues, builds and runs correctly. I don't have anything to commit at the moment as most of the changes I made were done in conjunction with Francois some time ago. I think Cobalt should be a separate module. It has nothing to do with the graph drawing code. The name suggestions should okay to me too. Regards, Martin Cully Mark Johnson wrote: > *Last week I updated my changes to ‘**netron/netrontry2’ and would be > interested in learning if any conflicts have accured.* > > *No more changes are planned at this point (the Font problem still > being, and will probably remain, unresolved).* > > * * > > *Have all other inclusions been merged to this Version ?* > > *Should the Cobolt Portion be included ?* > > * * > > *What final name should be chosen ?* > > * * > > *My suggestion would be something like ‘netron_F11’ with a ‘netron_F20’ > for a Framework 2.0 coming later.* > > *Francois Vanderseypen sagt:* > > *the name is fine for me* > > * * > > *Once everything is in, I would ‘checkout’ the last Version and check it > out with my code.* > > * * > > *If everything then works for all, we could the make a general > announcement with the final Name (also updating the CVS-Page from ‘NAF’ > to the new name) with this being the present Framework 1.1 Version of > Netron.* > > * * > > *Mark * > > * * > > * * > > * * > > * * > > * * > > > ------------------------------------------------------------------------ > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.1.371 / Virus Database: 267.13.12/194 - Release Date: 07/12/2005 > |
|
From: Mark J. <mj...@we...> - 2005-12-08 06:21:56
|
Last week I updated my changes to 'netron/netrontry2' and would be interested in learning if any conflicts have accured. No more changes are planned at this point (the Font problem still being, and will probably remain, unresolved). Have all other inclusions been merged to this Version ? Should the Cobolt Portion be included ? What final name should be chosen ? My suggestion would be something like 'netron_F11' with a 'netron_F20' for a Framework 2.0 coming later. Francois Vanderseypen sagt: the name is fine for me Once everything is in, I would 'checkout' the last Version and check it out with my code. If everything then works for all, we could the make a general announcement with the final Name (also updating the CVS-Page from 'NAF' to the new name) with this being the present Framework 1.1 Version of Netron. Mark |
|
From: Francois V. <Fra...@sk...> - 2005-11-26 06:46:56
|
Martin, I have been looking recently at the Prefuse project and the approach to filtering and pre-rendering actions is very well worked out. Have a look at the papers (e.g. http://jheer.org/publications/2005-prefuse-CHI.pdf) or have a look at the code. The picture halfway in the paper represents well the idea. I am currently converting the code to C#, so maybe you can benefit from it if your approach the idea in a similar fashion for Netron. F. |
|
From: Martin C. <mar...@ei...> - 2005-11-25 16:04:35
|
Hi All, Before I look at implementing it, has anyone extended the library to allow filtering of the displayed shapes based on property values? Would others find a generic filtering mechanism useful? Let me know what you think? Regards, Martin |
|
From: Francois V. <Fra...@sk...> - 2005-11-24 20:46:27
|
Hi Netron devels, This mailing list is at your disposal to communicate all your wishes, frustrations and dreams related to the graph library developments. The list is NOT public and only four people (besides myself) are subscribed: Eran (er...@e-...) Hernan (hfo...@ho...) Martin (mar...@ei...) Mark (mj...@mj...) Note that you can only use the Email with which you are subscribed to send mail. If you wish to use another, give me a sign. As we discussed at our last chat, the CVS should be up and running one of these days (Eran, any progress?). Many people look forward to new graphlib features and eagerly wait for news and updates. I get many Emails and sometimes I wished I could make them public or share them in some way, but time and space is limited. Anyway, hope all is well on your side, F. |
|
From: Martin C. <mar...@ei...> - 2005-11-24 20:39:59
|
Hi All, Just a test post to see if all is working okay. Regards, Martin |
