Lazarus
Miscellaneous => Suggestions => LCL => Topic started by: JuhaManninen on May 03, 2013, 11:25:30 am
-
TArrow was recently improved but it needs a revamp. It uses widgetset bindings which is not needed. The arrow is always drawn using graphics primitives. TArrow is an odd bird in the middle of Misc component tab. It does not really do anything. It only shows an arrow.
There could be a new "Industrial stuff" component tab with rewritten TArrow, then TLed, TLedNumber, TSemaphore, TPipe(s) etc.
The components would inherit from TGraphicControl.
If somebody is willing to make such lib or donate an existing one, it would be nice.
There are libraries like that, not sure if any are free / open.
-
Have you looked at Cindy components converted from Delphi by Lazarus CT team? It's not IOCOMP but still has useful and nice looking components. If I remember well it had MPL license.
-
Have you looked at Cindy components converted from Delphi by Lazarus CT team? It's not IOCOMP but still has useful and nice looking components. If I remember well it had MPL license.
I found this thread about Cindy components :
http://www.lazarus.freepascal.org/index.php/topic,13430.0.html
They look nice but the lib is much bigger than what I wanted for the new tab. The new comps should be simple and not pull in much dependencies.
CodeTyphon policy puzzles me. It seems they always fork the libraries they include in their product. They don't improve the original library by sending patches and maybe becoming developers.
I find it strange because those libraries often have lack of development resources, they would be happy to get contributions.
There would be no conflict of interest if CodeTyphon improved them and then included them in their product.
Yet, they have right to fork any GPL or MPL SW of course. I don't say it is bad, I am only wondering of the reasons.
They are clearly talented programmers there, kudos for that.
-
CodeTyphon policy puzzles me. It seems they always fork the libraries they include in their product. They don't improve the original library by sending patches and maybe becoming developers.
I find it strange because those libraries often have lack of development resources, they would be happy to get contributions.
There would be no conflict of interest if CodeTyphon improved them and then included them in their product.
Yet, they have right to fork any GPL or MPL SW of course. I don't say it is bad, I am only wondering of the reasons.
They are clearly talented programmers there, kudos for that.
I share your concern about CodeTyphon. I still don't understand their "raison d'etre". Why don't they give back their changes to the original component authors? It would surely be better for everybody.
JD
-
I still don't understand their "raison d'etre". Why don't they give back their changes to the original component authors? It would surely be better for everybody.
I share your point of view and I would also like them to improve original libraries instead, but just think about it. CT has more then 1000 components now. Would it be practical to contact 100 developers, work with their GIT, Mercurial, SVN, or even no CVS at all, and wait for patch approvals? Some developers are easy to work with, and some are not. Or if CT patches never get official then maintain that mess on so many version control systems? I would loose compass probably at 1/5 of current components, so I understand their approach. Probably not the best way, but it is practical and it works for them. They made many Laz/Delphi windows only components working on Linux, WinCE, FreeBSD and Solaris. And they really welcome suggestions for component conversions. If component is accepted, they do all the work. How bad can that be? Looking at other similar projects, Lazarus needs some big company sponsor to get attention it deserves. Till then, small CT team has done more for Lazarus then any other company I am aware of (please correct me if wrong). All that development time might not be in the direction everyone would like, but it's their time and they can spend it whatever they like. At the end we all benefit. Even people who don't find CT team's approach fit for their own development work, download Lazarus CT edition just to get new components or update old ones. I would expect some easier way to find a licensing terms for each component set, but hopefully that will be addressed soon. Some people don't like CT changing default toolbar positions, but if you can't wait for official solution which will make everyone happy, then look at their patches directory, find the 'evil one' and recycle it. Many people complained about hard time to reinstall everything with each new release, so CT team addressed it with a rolling update feature, which in theory should let you install LazCT just once and then just update it. I haven't tested that yet but it sounds promising and should solve a big problem CT had (it was not easy to update LazCT like Laz could). I myself use LazFPCUP and LazCT. In my opinion they are both great and solve different things. With fpcup I can easily test latest fpc/laz and keep older versions, or test some new component (waiting zillion components in CT with many active targets to recompile can not be called fast), or chase if some new bug existed with old fpc/laz. CT on the other hand is useful for it's zillion components and it's cross compile features.
-
True, the coordination between CT and the numerous library projects would be difficult. I guess they decided to only fork and never contribute for this reason. It is understandable.
Unfortunately sometimes it leads to duplicated effort. The original project is developed further and CT develops their forked version. Later it is very difficult to merge them.
-
I guess they decided to only fork and never contribute for this reason. It is understandable. Unfortunately sometimes it leads to duplicated effort. The original project is developed further and CT develops their forked version. Later it is very difficult to merge them.
Merging would be difficult if they continued enhancing forked components. I didn't see them doing that. They do the hard conversion from Delphi work, they make component compatible with as many targets as they can, they do the testing on all supported targets, they maintain merging with original component when it gets updated, contribute bug fix patches if there are any to the author, and that's all they do with a component if I understood them well. I might be wrong, but I didn't see them enhancing someone else's components if they didn't need it for the IDE or for their work. So, not much duplicated work after all. Just maintaining conversion patches when new component version shows up and they decide to update.
-
TArrow was recently improved but it needs a revamp. It uses widgetset bindings which is not needed. The arrow is always drawn using graphics primitives. TArrow is an odd bird in the middle of Misc component tab. It does not really do anything. It only shows an arrow.
There could be a new "Industrial stuff" component tab with rewritten TArrow, then TLed, TLedNumber, TSemaphore, TPipe(s) etc.
The components would inherit from TGraphicControl.
If somebody is willing to make such lib or donate an existing one, it would be nice.
The attached package could be a start for such a library. It contains a single TGraphicControl-derived arrow component. I've made it compatible with the existing TArrow in terms of properties and defaults, but disengaged it from any widgetset, and published Color and ArrowColor properties which TArrow lacks. It repaints immediately on property changes as components should (unlike TArrow), aligns correctly and sets minimum Height and Width constraints to reasonable values. I wondered about publishing the Enabled property, but decided there was little call for a visually distinct disabled arrow; nor could I decide what such a disabled arrow should look like. I'm also unsure whether there is any point in publishing drag/drop event handlers, so I've included them, but commented them out. I don't know how the "In" TShadowType enumerations should differ in appearance from "Out" TShadowTypes, so in this implementation they are identical, meaning that there are really only three shadow types (None, unEtched and Etched), although I've used the enumerated TShadowType which TArrow introduced without changing it. There is no unit test provided. It's more a proof of concept which a more experienced developer could refine.
-
hello,
howardpc, good job, your component seems to be OK ( only tested in Windows 7) . I have put your component in a package named industrialStuff. i have added two other components Tled and TledNumber, converted from delphi for tled ( source freeware) and modified from the component TvPLedLabel (package VisualPlanIt License MPL) for TledNumber. I don't know if it is what Juha hopes. While Waiting look at the attachments. If i am in the good way, soon i will put the source here.
Friendly, J.P
-
finally, my component Tled isn't OK on Linux :(
don' t reinvent the wheel : the components from codeTyphon Cindy TcyLed and TcyAdvLed do the job.
The files used for these components are :
cyBaseLed.pas, cyLed.pas, cyAdvLed, cyTypes.pas, cyGraphics.pas, cyClasses.pas, cyBevel.pas.
delta Exec File size (win32 with option -Cx -Xs -XX) in my example with one component cyLed : 12 kb
the cyAdvLed use pictures for drawing the states. So the size depends of the size of the pictures.
For LedNumber there are also components in codeTyphon :
TplLed7Seg, TplLCDLine from extra Controls package and TvpLedLabel from Visual PlanIt package.
For Arrow look at TplSolidArrow in the Shapes package.
Friendly J.P
-
Sorry for the delay guys. I almost missed the latest posts because there is so much traffic here.
The attached package could be a start for such a library. It contains a single TGraphicControl-derived arrow component. I've made it compatible with the existing TArrow in terms of properties and defaults, but disengaged it from any widgetset, and published Color and ArrowColor properties which TArrow lacks.
[...]
Vey nice!
I replaced the old TArrow component with yours. I only changed the name to TArrow and registered the component on "Industrial" tab, otherwise no changes.
I was able to remove tons of useless widgetset binding code, see r41221 yourself.
Thank you howardpc for this contribution.
This component is needed in the IDE, that is why I did not put it in a separate package. It is in LCLBase just like the old version was.
For example it is needed in the designer menu editor. The future "IndustrialStuff" package (or whatever name it has) should not be pulled in for the basic IDE compilation.
Now, the plan still is to have a new package. The components in that package would go to the same "Industrial" tab as the TArrow.
The requirements are :
1. Cross-platform
2. License is usable, LGPL or similar.
3. Not too many dependencies.
Number 3. worries me the most now.
Extracting from Cindy components is basically OK, but does it mean pulling lots of extra code with it?
If yes, then it would be better to include the whole Cindy lib.
There is also a question of positioning our project in the "market". Should we compete with CodeTyphon by including external libraries? IMO no, we have enough work with the IDE + LCL.
Yet, some light and often needed graphics components (led, semaphore etc...) could be usefull.
Jurassic Pork, what is your opinion?
Regards,
Juha
-
The Leds components of Cindy package haven't too many dependencies :
The files used for these components are :
cyBaseLed.pas, cyLed.pas, cyAdvLed, cyTypes.pas, cyGraphics.pas, cyClasses.pas, cyBevel.pas.
delta Exec File size (win32 with option -Cx -Xs -XX) in my example with one component cyLed : 12 kb
the cyAdvLed use pictures for drawing the states. So the size depends of the size of the pictures.
those components are ok on ubuntu. Also The TArrow.
i don't know what you name "LedNumber" LCD 7 Segment ?
and what is semaphore ? pipe ? a good link to see what they are 8) ?
Sorry for my poor english
Friendly J.P
-
[...]
i don't know what you name "LedNumber" LCD 7 Segment ?
and what is semaphore ? pipe ? a good link to see what they are 8) ?
Semaphore is like traffic lights.
Pipe is actually from Zeljan's list when we discussed this library. I am not sure what kind of pipe it would be. Must ask him.
7-Segments and such fit well into this idea.
If you want to collect a nice set of those components and put them into a package, please go ahead. I will add it under Lazarus components directory.
The name "Industrial Stuff" is also from Zeljan. I don't know why it is Industrial but I don't know any better name either.
The package name could be just "industrialstuff.lpk" unless there are better ideas. The component tab is already "Industrial" but it can be changed if needed.
-
hello, Juha
in the attachment picture, tell me what the components you would want to be included in the industrial stuff. For the moment the components TStopLightSensor and TAnalogSensor are not sure.
For the pipe --> are they thick poly lines ?
Friendly, J.P
-
in the attachment picture, tell me what the components you would want to be included in the industrial stuff. For the moment the components TStopLightSensor and TAnalogSensor are not sure.
They all look good, although I don't know how the AnalogSensors on last row work.
TgrArrow is already in LCL and renamed to TArrow.
What means the "converted from Delphi"? Are they your self-made Delphi components originally?
For the pipe --> are they thick poly lines ?
I will figure out what Zeljan meant.
The idea is a Pipe or Tube which connects some other graphs or components together and shows an animated liquid or electricty flowing inside. The animation shows the direction of movement.
-
The name "Industrial Stuff" is also from Zeljan. I don't know why it is Industrial but I don't know any better name either.
There is a specialized development software called SCADA (Supervision Control and Data Acquisition) which is used for visualization of plant production lines usually run by PLCs (Programmable Logic Controllers). All those virtual instruments, pipes, lines, arrows, animated conveyors, vessels and other represent HMI (Human Machine Interface) and have their origins in such software. Terms widely used are Industrial Automation and Process Control. I guess that's why the name "Industrial Stuff" was chosen. If it was me, I would probably call it a little different. Something like Industrial Automation Visualization (since it's only used for visualization of industrial automation). Or VIAC (Visual Industrial Automation Components). Or IPV (Industrial Process Visualization). Or PCV (Process Control Visualization). Or simply HMI. Or ... you name it.
Btw. anyone interested in SCADA should take a look at PascalSCADA (http://www.pascalscada.com) which is also included in Lazarus CT.
-
There is a specialized development software called SCADA (Supervision Control and Data Acquisition) which is used for visualization of plant production lines usually run by PLCs (Programmable Logic Controllers). All those virtual instruments, pipes, lines, arrows, animated conveyors, vessels and other have their origins in such software. Terms widely used are Industrial Automation and Process Control. I guess that's why the name "Industrial Stuff" was chosen. If it was me, I would probably call it a little different. Something like Industrial Automation Visualization (since it's only used for visualization of industrial automation). Or VIAC (Visual Industrial Automation Components). Or IPV (Industrial Process Visualization). Or PCV (Process Control Visualization). Or ... you name it.
Thanks for the explanation.
I think "Industrial" is a good name for the tab. "Industrial Automation Visualization" is too long.
VIAC, IPV and PCV are short but most people don't know them and would have to look for the meaning somewhere.
Besides, Industrial is surely more descriptive than Misc or Additional.
Btw. anyone interested in SCADA should take a look at PascalSCADA (http://www.pascalscada.com) which is also included in Lazarus CT.
I downloaded it now from SVN repo and installed. It seems to have a different goal. It is controlling the actual processes and devices. I don't see any LEDs or other graphs there.
Our lib should be simple and graphics oriented. Zeljan suggested a new base class with common properties for all "Industrial" components.
Initially it would have AntiAliasingMode.
People could use this lib as a base for a SCADA solution or anything fancy.
Anyway, now we can shamelessly pull code from existing components and libs. This is the essence of GPL. The license and copyright notes must be preserved of course.
-
@Avra: nice post. Other possible names: Industrial Visualization Components, Industrial Components.
Edit: @Juha, yes just Industrial makes sense as well. Agreed about the abbreviations.
-
Anyway, now we can shamelessly pull code from existing components and libs. This is the essence of GPL. The license and copyright notes must be preserved of course.
I would not like to see default Lazarus distribution polluted by GPL-ed components. If their license cannot be turned into modified LGPL, let us better create them from scratch.
-
I think "Industrial" is a good name for the tab. "Industrial Automation Visualization" is too long.
VIAC, IPV and PCV are short but most people don't know them and would have to look for the meaning somewhere.
If single word is prefered, then people who are interested in such stuff would probably like to call that tab HMI (Human Machine Interface) since that is a well known acronym and everyone in the business knows what it means.
Btw. anyone interested in SCADA should take a look at PascalSCADA (http://www.pascalscada.com) which is also included in Lazarus CT.
I downloaded it now from SVN repo and installed. It seems to have a different goal. It is controlling the actual processes and devices. I don't see any LEDs or other graphs there.
Huh, sorry for providing a confusion. I didn't mean to mention it as a source of visual components. It can link to visual components but it self it only provides a few standard components which are not ones you are looking for. I have mentioned it only as a reference for people looking for creating SCADA applications with Lazarus.
-
i have made an experimental package named Industrial :-X with 7 components :
TindAdvLed, TindLed, TAnalogSensor, TgrArrow, TStopLightSensor, TLEDNumber.
Project with only a Form Win7 Lazarus 32 compiled no debug optimized 2 smart link :
initial executable size : 1606 Kb
Same project with the seven components ( one by type) : 1665 kb
it seems that the components are not too big .
attachment pictures : Industrial Tab and example
Friendly, J.P
-
hello, Juha
in the attachment picture, tell me what the components you would want to be included in the industrial stuff. For the moment the components TStopLightSensor and TAnalogSensor are not sure.
For the pipe --> are they thick poly lines ?
Friendly, J.P
Cindy components looks good. Are they open source ?
-
only the Leds components come from Cindy package
The license for Cindy package is :
* ***** BEGIN LICENSE BLOCK *****
*
* Version: MPL 1.1
*
* The contents of this file are subject to the Mozilla Public License Version
* 1.1 (the "License"); you may not use this file except in compliance with the
* License. You may obtain a copy of the License at http://www.mozilla.org/MPL/
*
* Software distributed under the License is distributed on an "AS IS" basis,
* WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License for
* the specific language governing rights and limitations under the License.
*
* The Initial Developer of the Original Code is Mauricio
* (https://sourceforge.net/projects/tcycomponents/).
*
* Alternatively, the contents of this file may be used under the terms of
* either the GNU General Public License Version 2 or later (the "GPL"), or the
* GNU Lesser General Public License Version 2.1 or later (the "LGPL"), in which
* case the provisions of the GPL or the LGPL are applicable instead of those
* above. If you wish to allow use of your version of this file only under the
* terms of either the GPL or the LGPL, and not to allow others to use your
* version of this file under the terms of the MPL, indicate your decision by
* deleting the provisions above and replace them with the notice and other
* provisions required by the LGPL or the GPL. If you do not delete the
* provisions above, a recipient may use your version of this file under the
* terms of any one of the MPL, the GPL or the LGPL.
*
* ***** END LICENSE BLOCK *****}
{**********************************************************************
Package pl_Cindy.pkg
for CodeTyphon Studio (http://www.pilotlogic.com/)
***********************************************************************}
-
I would not like to see default Lazarus distribution polluted by GPL-ed components. If their license cannot be turned into modified LGPL, let us better create them from scratch.
Yes sorry, I meant LGPL, not GPL.
@avra:
HMI (Human Machine Interface) can also mean the technical assistance for disabled people which is an interesting topic with brain implants and everything. ( www.youtube.com/watch?feature=player_embedded&v=ogBX18maUiM )
The acronym is quite loaded already: http://en.wikipedia.org/wiki/HMI
> Huh, sorry for providing a confusion.
No confusion. I just wanted to see what the library does.
@Jurassic Pork:
Please use a new TIndustrialBase class, see r41234 and r41235.
Remove TgrArrow as it is already in LCL with name TArrow.
CodeTyphon once copied the Cindy components. Now we copy from them. I always said copy-pasting is the highest level of programming. :)
-
I prefer to stop now the development of this package because i am not a professionnal programmer :-[
i give you the sources of my experimental package with the example int the file attachment. Take what you need . And if you have questions about the sources, post a message in the forum :)
Friendly J.P
-
I prefer to stop now the development of this package because i am not a professionnal programmer :-[
i give you the sources of my experimental package with the example int the file attachment. Take what you need . And if you have questions about the sources, post a message in the forum :)
Thanks!
I have applied it to components/IndustrialStuff.
I went through the code, removed some compiler warnings and wrong project settings in the example and ... everything seems to work.
Only the TindAdvLed feels unintuitive to use. By default it does not show anything. Green and red images could be loaded by default if they exist.
Patches and more components are welcome, but nothing very big please. I already got a question about why this lib is not developed in CCR. This must be kept simple and light.
-
For the TindAdvLed in the example, i have forgotten to load a picture for the OFF and DISABLE State and also forgotten to put the property autosize to true ( better look).
In brief :
Tpicture for DISABLE state : CMP_Button_disa.png in the ButtonSamples folder
Tpicture for OFF state : CMP_Button_off.png
Tpicture for ON state : CMP_Button_on.png
May be it would be interesting to load by default these pictures (put in a lrs) in the component.
Don't forget that in this component you could not change the color with a property. You must change the picture to change the color. Another way should be to add a color property and to do in the bitmap what is done for example in Lazpaint/Colors/shift Colors modify the hue (test this with the CM_Button_on.png picture).
Friendly, J.P
-
I removed all unused code that was copied with the Cindy lib files. It looked a little bloated.
I also replaced {$MODE Delphi} with {$mode objfpc}{$H+}.
It already revealed one error in 64-bit compilation in unit cyBaseLed which was easy to fix:
- Msg.LParam := Longint(Self);
+ Msg.LParam := PtrInt(Self);
CodeTyphon should use {$mode objfpc} as well. The same bug is still in their code.
Some Lazarus developers think this package should be in Lazarus-CCR.
Let's see what will happen. I personally like it this way. For example LEDs are often useful in a GUI but I am lazy to download and install external libs for it.
Patches are welcome for TindAdvLed and for other comps. I move to other tasks now...
Juha
-
New component in progress for Industrial package TAdvLed
Replacement of component indAdvLed :
created from TComled of ComPort Library ver. 3.00 written by Dejan Crnila
( license : public domain)
Features :
Inherited from the TCustomImage Class
Three states : disabled, off, on
Four natives Kinds : red, green, yellow, bulk.
A custom Kind : to use external pictures.
Blink mode with adjustable duration.
Tested on Windows 7 Lazarus 32 bits 1.1
Ubuntu 12.04 CodeTyphon 4.20 (Lazarus 64 bits 1.1)
Friendly, J.P
-
Nice! Congratulation!
Best regards
-
New component in progress for Industrial package TAdvLed
Replacement of component indAdvLed :
There is already a bug report about indAdvLed. I guess it does not need fixing.
http://bugs.freepascal.org/view.php?id=24464
-
The bug come from the fact that in the TControl class the property Hint is published not the property ShowHint which is public. You must publish this property in your component so that you can edit it if the inherited classes of your component don't have this property published.
The components of Cyndy et EXControls package( codetyphon) have this problem and also some components of industrial package. The components TanalogSensor and TStopLight sensor haven't this problem because they inherit from Tpanel class which have the property ShowHint published.
Friendly, J.P
-
Industrial component Tab
Component Tarrow origin: TgrArrow Author Howardpc license GPL ? ask to Howardpc
Component TindAdvLed origin:TcyAdvLed from Cindy Package (codeTyphon) license : MPL alternatively GPL LGPL
Component TindLed origin : TcyLed from Cindy Package (codeTyphon) license : MPL alternatively GPL LGPL
Component TLedNumber origin : TVPLedLabel from VisualPlanIt Package (codeTyphon) license : MPL
Component TAnalogSensor,TStopLightSensor origin : sensors.Pas delphi license : Freeware (with sources)
Component TindGnouMeter origin : TplGnouMeter from Extra Controls package (codeTyphon) license : MPL alternatively GPL LGPL
The component TindAdvLed will be replace by TadvLed origin : TcomLed from Comport package delphi license : public Domain
If necessary TLedNumber could be replaced by TplLCDline from Extra Controls package (codeTyphon) license : MPL alternatively GPL LGPL
for the update a big patch ( many files have changed , others have been deleted, others have been renamed) or the complete package (modified and build from the last svn lazarus) ?
-
Ok, there was an issue with licenses after all. I did not look at it carefully enough.
Component Tarrow origin: TgrArrow Author Howardpc license GPL ? ask to Howardpc
Howardpc, is it OK to change it to LGPL? A component included in LCL cannot be GPL.
Component TLedNumber origin : TVPLedLabel from VisualPlanIt Package (codeTyphon) license : MPL
MPL is good, isn't it?
Component TAnalogSensor,TStopLightSensor origin : sensors.Pas delphi license : Freeware (with sources)
...
The component TindAdvLed will be replace by TadvLed origin : TcomLed from Comport package delphi license : public Domain
What do these mean in practice? Can they be used?
The license issues are boring. In most cases the author has no objections for using his component, but we still must get the license terms right.
for the update a big patch ( many files have changed , others have been deleted, others have been renamed) or the complete package (modified and build from the last svn lazarus) ?
In this case it makes no difference. I am not touching the package now, I will just apply your changes.
In future the package may indeed move to Lazarus-CCR. You could well be the maintainer of it.
-
Component TAnalogSensor,TStopLightSensor origin : sensors.Pas delphi license : Freeware (with sources)
...
The component TindAdvLed will be replace by TadvLed origin : TcomLed from Comport package delphi license : public Domain
What do these mean in practice? Can they be used?
Yep, public domain is basically "do whatever you want".
If no further terms are specified, IMO, freeware specifies the same thing: "do whatever you want".
-
in attachment the package IndustrialStuff (check new files, modified files , deleted files). Juha tell me if is it good for you.
ShowHint property now visible in all the components.
TadvLed replace TindAdvled
Example updated
Friendly, J.P
-
in attachment the package IndustrialStuff (check new files, modified files , deleted files). Juha tell me if is it good for you.
ShowHint property now visible in all the components.
TadvLed replace TindAdvled
I applied it. Thanks.
I removed IndAdvLed. I will check other files to be removed.
A patch is actually nice also for big changes like this. It handles removed files as well.
-
it seems to be OK now. I have updated my Lazarus with the revision 41377. Tested on Win7 lazarus 32 bits and Ubuntu 12.04 64 bits.
the files to be deleted :
in source folder :
cyBaseLed.pas
cyClasses.pas
cyGraphics.pas
cyTypes.pas
For the MPL 1.1 Licence read this http://www.mozilla.org/MPL/1.1/annotated/ (http://www.mozilla.org/MPL/1.1/annotated/)
Friendly J.P
-
Howardpc, is it OK to change it to LGPL? A component included in LCL cannot be GPL.
Sure LGPL is fine. In fact, I mistakenly thought it already was. I'd also be happy for the copyright to be
(C) 2013 Lazarus team
or something similar. Components included in Lazarus ought to have the most flexible and open licensing possible to fit the wider open source philosophy. I'm glad that the Lazarus community is basically about sharing, and openness to improvement by others to yield the highest quality software it is realistic to achieve.
-
Sure LGPL is fine. In fact, I mistakenly thought it already was.
Ok, I should verify before writing anything. The license already is LGPL, more precicely "GNU Library General Public License".
Jurassic Pork, why did you write it is not?
The whole header is copied below. I have earlier moved the Copyright text below license header and added the Abstract description.
Does anybody see a problem there?
One thing though. "Copyright (C) 2013 H. Page-Clark" could be changed to "Author: H. Page-Clark" for consistency reasons as other LCL and IDE files as marked that way. I don't know what the law says. Is the author automatically the copyright holder, or is it automatically the "Lazarus team" which distributes the files? Anyway it is not important because of the license terms.
{
***************************************************************************
This library is free software; you can redistribute it and/or modify it
under the terms of the GNU Library General Public License as published by
the Free Software Foundation; either version 2 of the License, or (at your
option) any later version.
This program is distributed in the hope that it will be useful, but WITHOUT
ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE. See the GNU Library General Public License
for more details.
You should have received a copy of the GNU Library General Public License
along with this library; if not, write to the Free Software Foundation,
Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
***************************************************************************
Copyright (C) 2013 H. Page-Clark
Abstract:
Show an arrow. Its size, direction, color and shadow can be adjusted.
}
-
as far as I can understand the law, everything created outside a contract is automatically copyrighted by the author otherwise that author would require to ask for permission when using that peace of code from the copyright holder. The copy you have is licensed under what ever terms the copyright holder has grand you and he can also give you the copyright if he wants to in which case he looses all rights on it.
Personally I would give my copyrigths to any one only a license to use freely but at the same time I want to be able to use that in any kind of situation with being hold down by gpl, mpl, MIT, or any other type of license.
Keep in mind I am not a lawyer so all the above are my interpretation of what lawyers have said.
-
Ok, I should verify before writing anything. The license already is LGPL, more precicely "GNU Library General Public License".
Note that there's a difference between the plain LGPL and the "modified LPGL" that is used in other components. See your lazarus dir, COPYING.modifiedLGPL.txt.
IMO, the modified LGPL works better as it spells out that you can create commercial works using the components.
The whole header is copied below. I have earlier moved the Copyright text below license header and added the Abstract description.
Does anybody see a problem there?
Moving stuff does not seem to be a problem. As mentioned above, if Howard agreed, I'd change the license to modified LGPL. Sample from fpvectorial.pas:
fpvectorial.pas
Vector graphics document
License: The same modified LGPL as the Free Pascal RTL
See the file COPYING.modifiedLGPL for more details
edit... though we're in Lazarus here, so something like this would be better (from components/lazcontrols/dividerbevel.pas):
Copyright (C) 2010 Lazarus team
This library is free software; you can redistribute it and/or modify it
under the same terms as the Lazarus Component Library (LCL)
See the file COPYING.modifiedLGPL.txt, included in this distribution,
for details about the copyright.
One thing though. "Copyright (C) 2013 H. Page-Clark" could be changed to "Author: H. Page-Clark" for consistency reasons as other LCL and IDE files as marked that way. I don't know what the law says. Is the author automatically the copyright holder, or is it automatically the "Lazarus team" which distributes the files? Anyway it is not important because of the license terms.
Copyright is automatically assigned to the author per the Berne copyright convention (IIRC most countries signed this, including US and European countries).
So in that sense it doesn't matter. IIRC, US law used to have some convention that you had to indicate you add copyright, but (once again IIRC) no fixed format for that. Regardless, the "Copyright (C) bla" convention began.
Edit: looking at Howard's post: he is happy with assigning the copyright to the "Lazarus team".... which is of course a bit of an amorphous group, but yes, it would broaden the openness as other members of the team (or the team itself, don't know, I'm - fortunately - not an IP lawyer) could relicense the code if they wanted. In that situation, Howard could still reissue his own code under whatever license he thinks fit.
In practice, I doubt it would matter much.
Thanks for looking into these pesky license issues for us.
-
<nitpick mode>
Jurrasic Pork's license notice could do with some changes, IMO:
(Note: he's probably a better programmer than I but I am probably more of a neurotic pedantic type. I therefore really don't mean this as criticism to JP. To each his own ;) )
* This file is part of Lazarus which is distributed under the modified LGPL* *
No. Lazarus as a whole is not distributed under the modified LGPL. E.g. the IDE itself is GPL, IIRC. Other components have their own licenses, or are double licensed.
* See the file COPYING.modifiedLGPL.txt, included in this distribution, *
* for details about the copyright. *
No, it's not details about the copyright, it's details about the license. Otherwise ok (though specifying where COPYING.modifiedLGPL.txt if it's not in the current directory would be almost obligatory).
* This program is distributed in the hope that it will be useful, *
* but WITHOUT ANY WARRANTY; without even the implied warranty of *
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. *
Now we get some snippet out of (presumably) the LPGL. Why is this here? Referring to the actual, complete license text makes this part unnecessary and ambiguous: does this section override the general license? Does it try to clarify/more precisely define that license?
I'd get rid of it.
I would therefore suggest replacing the above with similar text to the dividerbevel.pas example I gave above.
</nitpick mode>
-
I would therefore suggest replacing the above with similar text to the dividerbevel.pas example I gave above.
Good catches BigChimp.
The same header text blocks are copied again and again. I copy them and so did JP.
BTW, your dividerbevel.pas example contains the same "details about the copyright" error you complained about.
I agree there is no reason to emphasize the lack of warranty. It is already mentioned in the license text with different wording.
The "WITHOUT ANY WARRANTY" with capital letters is so American.
When would someone insist to have warranty for LGPL SW? If the TArrow component causes somebody's computes to explode then he will sue us. (?)
Rather hypothetical, and already covered in the license.
I am planning to fix those issues in all source files. If other developers have objections, it can always be reverted.
-
BTW, your dividerbevel.pas example contains the same "details about the copyright" error you complained about.
LOL ;)
I am planning to fix those issues in all source files. If other developers have objections, it can always be reverted.
Ok, big dreary task but it will definitely clarify things.
While you're at it would you know under what license
($LazarusDir)/images falls? It does not contain any license info about the image files that are there.
($LazarusDir)/COPYING.txt does not mention the license situation.
http://bugs.freepascal.org/view.php?id=23780
Thanks for the hard work!
-
While you're at it would you know under what license ($LazarusDir)/images falls?
I have no idea.
-
No problem... somebody will sometime ;)
-
You might like to look at the attached numerical LED component I've written based on the look of a classic 7-segment number LED. It supports integers from -maxint to +maxint, and offers both hex and decimal display and left, right and centred alignment.
Because it is 'pure' Lazarus code it supports Align, anchors and Autosize which the Cindy components (as Delphi ports) are not so good at. It is also quite lightweight (9kb zipped including the icon).
-
hello howardpc, good job about your component, but the component lednumber used actually in IndustrialStuff is more "generic" , it can have alphanumeric characters, more than one line ... for the missing properties, it will be easy to add them in the published part of the component ( public in the ancestor class). Would it be better to adjust or improve the existant components ? for example preferred size constraints etc...
to do :
may be change the name for lednumber ---> ledalpha
the delphi converted components have some properties to be published ( for example ancestors)
bug 24472 mantis :
place a component with photo and change it size, place the other side with the same photo and do not change the size ... see that all two had the same size ... I eliminate the line Autosize = true when the problem is solved
not the good solution to eliminate the line , better solution
replace
property AutoSizeby
property AutoSize default true;in the published properties
other bug :
png picture have only one bit alpha transparency on lazarus linux gtk ---> the png pictures of the advled are not very beautifull on linux because they are 8 bits alpha transparency pictures.
Friendly J.P
-
howardpc and Jurassic Pork,
you must start providing patches, preferably uploaded to a issue report, after you agree about what must be done.
I don't have opinions for this. I would happily give the maintenance of "Industrial" package to one of you.
What do you think if I move the package to Lazarus-CCR and ask for commit access for one of you?
The idea was to move it to Lazarus-CCR later when a new integrated package download / installation system (Aarre) works in Lazarus, but it could be moved already now.
-
Hello Juha,
i think that Howardpc has more experience that me with lazarus and svn. il woud be a better "comitter".
For the patches, i have answered to the bug 24472 mantis with a patch. Can you tell me if the patch is in a good format ( i use tortoise svn)?
-
i think that Howardpc has more experience that me with lazarus and svn. il woud be a better "comitter".
That is an excuse. Commiting changes is as easy as creating a patch.
Anyway, what does Howardpc say? Do you want to be a maintainer?
For the patches, i have answered to the bug 24472 mantis with a patch. Can you tell me if the patch is in a good format ( i use tortoise svn)?
Yes it is OK.
Now that you asked it, the best patch would be made from the source root directory so that file paths are included, too.
Then I can apply it from the root dir without worrying about paths.
$ patch -p0 < ~/patch/AdvLed.pas.patch
With your patch I must first move to the right source directory and then apply.
$ cd components/IndustrialStuff/source/
$ patch -p0 < ~/patch/AdvLed.pas.patch
No big deal, but with some patches I don't know where the file is. I must first search it to get its path.
A patch made from the root directory is also more self-documenting. I see the paths in Kompare (diff viewer) and can use them for opening files in editor for example.
-
How to change the colors of AdvLed? I think it is strange the states lsOff and lsDisabled are some kind of gray, and lsOn is red - I'd expect lsOn to be green, lsOff red and lsDisabled gray, and maybe other users have different preferences.
-
to change the color -> change the kind :
lkRedLight, lkGreenLight,lkYellowLight
for the moment only the state lson change the color : the lsOff and lsDisabled display a dark led
you can use the kind lkcustom to put your state's pictures.
May be in the future , this will be improve.
-
Anyway, what does Howardpc say? Do you want to be a maintainer?
No I would rather let Jurassic Pork take this on, though I am happy to help working on bugs or whatever might be needed, in collaboration with whoever becomes the maintainer. Like JP I have no experience with SVN except using Tortoise to copy/update a few open source repositories to make them local (though obviously it would be good to learn more).
My principal interest is in documentation of existing components and libraries (not in producing ever more components), and if I were to give significant chunks of time to Lazarus as a commitment, then documentation is the area I would be motivated to help with in terms of maintenance.
-
FYI: Patch with description for the package at
http://bugs.freepascal.org/view.php?id=24479
Thanks for Avra for the abbreviations ;)
Also, I think one of the controls is called TStopLight. While that is very understandable to me (it's the Dutch term for traffic light) I wonder whether it is good/comprehensible English.
Wouldn't TTrafficLight be better? (I would hate something like TSemaphore - I'm always thinking of interprocess communication).
Your thoughts?
-
FYI: Patch with description for the package at
http://bugs.freepascal.org/view.php?id=24479
Also, I think one of the controls is called TStopLight. While that is very understandable to me (it's the Dutch term for traffic light) I wonder whether it is good/comprehensible English.
Wouldn't TTrafficLight be better? (I would hate something like TSemaphore - I'm always thinking of interprocess communication).
TStopLight is eminently comprehensible English (albeit American rather than UK) and has the minor advantage that it is slightly shorter to write. American/British distinctions are increasingly blurred and unimportant in the internationalised web environment, and the LCL usually reflects American spellings where they differ from UK spellings, since it is VCL compatible, and of course the VCL came first and was 100% American. I agree that TSemaphore is a confusing misnomer.
-
@Howard: thanks for the explanation - seems like TStopLight is here to stay ;)
-
Hello. Very good job. Thanks !
I wonder if this set of components available and ready for Lazarus.
After reading the entire post it is not clear to me if it is available and where to get it.
Thanks folks
Daniel
(sorry my english)
-
In Lazarus, go to Package/Install/Uninstall Packages..
then in the "Available for installation" list look for Industrial
If it's there, you can mark it for installation & rebuild Lazarus.
If not, easiest is probably to upgrade Lazarus. I don't know in which version these components appeared; have a look at the release notes for the various versions on the wiki for details, e.g.
http://wiki.lazarus.freepascal.org/Lazarus_1.2.0_release_notes
-
They are present in 1.2. Install them by following what BigChimp explained in previous post.