Re: [Kicad-developers] Damned the 'undefined global constructor order'
On 2014.06.09 19:56, Lorenzo Marcantonio wrote: How could I solve this? Solution 1) explode in the presets the whole list of layers in TECH_FRONT. Not exactly elegant Solution 2) convert the TECH_FRONT constant to a function which always return the correct value; best way to fix it I found until now (however every time it recomputes the whole or chain...) Solution 3) the preset could be moved inside the only function using it... sadly not a general case solution Solution 4) ??? anybody knows some idiomatic form/magic pattern to avoid the problem? A common solution to this problem is to never use global static variables. Instead, create a function that contains a local static variable of wanted type and returns a reference to it. The variable will be constructed on the first invocation of the function. In this way all invocations of such global constructor functions will be serialized as the dependencies become explicit. Cheers, Povilas ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Jenkins halted?
On 2014.06.02 13:15, Povilas Kanapickas wrote: I've just pushed some hundred of commits that have accumulated. The mirror won't update each 10 minutes for now, that will be fixed in the near future. Cheers, Povilas The mirror is again being updated each 10 minutes. Cheers, Povilas ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Jenkins halted?
On 29/05/14 16:15, Nick Østergaard wrote: Hello I am not sure who maintains the Jenkins build bot at http://ci.kicad-pcb.org/, but I have noticed that is has stopped. I am not sure who runs that, so I write to the list. Also the kicad-source-mirror on github has stopped updating. Is it the same person that maintains those services? Hi, I've had a hard drive failure and haven't fully recovered my working environment yet. I expect to fix the issue and start updating the mirror in the coming days. Sorry for the inconveniences :-) Cheers, Povilas ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Jenkins halted?
On 02/06/14 12:36, Povilas Kanapickas wrote: On 29/05/14 16:15, Nick Østergaard wrote: Hello I am not sure who maintains the Jenkins build bot at http://ci.kicad-pcb.org/, but I have noticed that is has stopped. I am not sure who runs that, so I write to the list. Also the kicad-source-mirror on github has stopped updating. Is it the same person that maintains those services? Hi, I've had a hard drive failure and haven't fully recovered my working environment yet. I expect to fix the issue and start updating the mirror in the coming days. Sorry for the inconveniences :-) Cheers, Povilas I've just pushed some hundred of commits that have accumulated. The mirror won't update each 10 minutes for now, that will be fixed in the near future. Cheers, Povilas ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Revisiting the Git decision
On 02/05/2014 08:25 AM, Miguel Angel wrote: Well, two interesting things here: 1) the git-bzr-ng looks great, we can add some documentation to the website based on what inkscape provides. This should make people more used to git happier, and we have an easy migration path if something goes wrong with launchpad or bzr (I don't foresee that, but ok). 2) Somebody commented that he had a script to sync bzr-git. Could you share it?, I'd love adding it to jenkins too for syncing the product branch to github, Jenkins could take care of doing this work, and sending an email if something goes wrong. 2.b) Even who knows, one day we could ask him to take the pull requests from github and send them as patches to the list... or we can just setup github to send notifications on pull requests to this repository to the list... FYI there's official git-bzr plugin that is distributed along git sources. It's probably better to use this plugin instead of git-bzr-ng for any permanent git-bzr bridges: the former, being in the official git sources, is likely to be better maintained in the long term. The kicad-source-mirror repository on github already uses it, the instructions for importing new changes are on the wiki[1]. Cheers, Povilas [1]: https://github.com/KiCad/kicad-source-mirror/wiki ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Proposal: reorganize the components library
On 12/07/2013 03:19 PM, Wayne Stambaugh wrote: On 12/7/2013 2:45 AM, Povilas Kanapickas wrote: I've already got a reply off-list that equivalent functionality is already developed (I couldn't find any discussions on the list until now unfortunately). It thus makes sense to scrap the proposal. Perhaps I can help whoever is working on the new library file format? Regards, Povilas This work is already complete and is about to become the default setting. Hopefully this will happen today. I'm just waiting to hear back from JP. There is really no coding left to be done other than fixing any remaining issues. You can test this code by building KiCad with the CMake flag -DUSE_FP_LIB_TABLE=ON. Even better, also set -DBUILD_GITHUB_PLUGIN=ON to enable the GitHub plugin. Then you will really appreciate the full potential of the new footprint library file format. The documentation for the GitHub plugin is currently only available in the developer documentation (I'm currently working on adding it to the user documentation as well) by running `make doxygen-docs`. Look at the GITHUB_PLUGIN class documentation for information on configuring the GitHub plugin. Wayne I'm fully aware that footprint libraries are already restructured :-) My proposal was about for the symbol libraries, i.e. those defined in *.lib files. AFAIK there's no alternative format for them yet, though I was told in an off-list email that some work is being done. Regards, Povilas P.S. Just out of interest, could someone give a two sentence overview over why custom, non XML/JSON/etc. format has been chosen for various serializers in KiCad? I've tried to search in the email archives but the decision and arguments for it seem to be burried sufficiently deep enough :-) ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] Proposal: reorganize the components library
I'd like to propose a new format for components libraries. The summary
of the proposal is as follows:
* XML is used as the serialization format
* one directory per library
* one file per component
* boost::property_tree is used as internal, abstract data format. This
allows translating to/from multiple file formats at the point of load/save.
I'm volunteering to implement a new library parser/writer and convert
all existing libraries to the new format, if the proposal gets accepted.
We could potentially introduce something very similar to the Github
plugin for component libraries too, however this is not part of this
proposal.
The detailed proposal is as follows:
* A library in the new format would be defined as a collection of files
in a directory. A directory would contain:
+ A file with extension '.kicad_symlib', in which some library-wide
information is specified
+ A collection of files with extension '.kicad_sym', each of which
define one component. I think it's worth to merge the component symbol
and the docs into a single file because:
- Everything could be kept in a single place
- The number of files would be reduced
- The docs don't take much space anyway
* The .kicad_symlib file would not list the symbols contained in the
library. The library parser should list all files within the directory
and try to parse each file with appropriate extension.
* The file name would be derived from the component name.
* The format of the files would be XML. This has the following advantages:
+ The format would be at least somewhat self-documenting
+ The format would be easily extensible
+ The format would allow much better interoperability with other
software, as tool/library support for XML is in great shape.
* Indentation amount would be set as a policy to eliminate any problems
during merges to the repository. The same for newline locations. I
suggest two spaces and one tag per line respectively.
* XML namespaces won't be used since they are not useful in this
particular use-case, yet would make the files less convenient to parse
using certain libraries.
* boost::property_tree library would be used as a parser. It is already
used in the KiCad codebase.
* The saving and loading routines would be modified to accept a path
instead of a generic stream. CMP_LIBRARY::{Save,Load} and
{Save,Load}Docs would be merged each with their respective sibling.
* The users of CMP_LIBRARY::{Save,Load} would not know exact layout of
the library. Existing functionality that depends on the layout would be
moved to within CMP_LIBRARY. For example, a new method
CMP_LIBRARY::Backup would be introduced.
* At first, parsers of both formats would be implemented as member
functions of CMP_LIBRARY. Once everything is tested, we could create a
plugin interface.
* New {Load,Save} overloads that accept boost::property_tree would be
created for all LIB_* types that support serialization. Eventually,
write support for old format would be removed: the format would be
supported by translating it to boost::property_tree at a single,
centralized location (though bidirectional translation is possible too,
if needed). We could support lots of other formats this way.
What do the developers think about this proposal?
Regards,
Povilas
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Proposal: reorganize the components library
I've already got a reply off-list that equivalent functionality is already developed (I couldn't find any discussions on the list until now unfortunately). It thus makes sense to scrap the proposal. Perhaps I can help whoever is working on the new library file format? Regards, Povilas ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] Proposal: Move to C++11 (time to revisit?)
There was a proposal to move to C++11 in April [1]. In the end, Wayne suggested[2] that we should wait until major Linux distributions ship with a (mostly) C++11-compliant compiler, so the proposal was not adopted. I think it may be worthwhile to revisit the issue. All major Linux distributions already ship GCC-4.8 as the default compiler: Debian testing: GCC 4.8.1 [3] Debian unstable: GCC 4.8.1 [3] Ubuntu 13.10: GCC 4.8.1 [4] Opensuse 13.1: GCC 4.8.? [5] Fedora 19: GCC 4.8.2 [6] According to wikimedia stats[7] the above distributions cover 98% of the market. The list is for the newest releases, older releases will use older complilers of course. Presumably, the users who stick to these older releases want stability and won't update to bleeding-edge KiCad anyway. Thus I think they are not very important as far as this proposal is concerned. Any opinions? Regards, Povilas [1]: https://lists.launchpad.net/kicad-developers/msg10091.html [2]: https://lists.launchpad.net/kicad-developers/msg10120.html [3]: http://packages.debian.org/search?keywords=gccsearchon=namessuite=allsection=all [4]: http://packages.ubuntu.com/search?keywords=gccsearchon=namessuite=allsection=all [5]: http://software.opensuse.org/package/gcc [6]: https://apps.fedoraproject.org/packages/gcc-c++ [7]: http://stats.wikimedia.org/archive/squid_reports/2013-10/SquidReportOperatingSystems.htm ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Proposal: Move to C++11 (time to revisit?)
On 12/04/2013 03:57 PM, Wayne Stambaugh wrote: On 12/4/2013 4:44 AM, Povilas Kanapickas wrote: There was a proposal to move to C++11 in April [1]. In the end, Wayne suggested[2] that we should wait until major Linux distributions ship with a (mostly) C++11-compliant compiler, so the proposal was not adopted. I think it may be worthwhile to revisit the issue. All major Linux distributions already ship GCC-4.8 as the default compiler: Debian testing: GCC 4.8.1 [3] Debian unstable: GCC 4.8.1 [3] Ubuntu 13.10: GCC 4.8.1 [4] Opensuse 13.1: GCC 4.8.? [5] Fedora 19: GCC 4.8.2 [6] According to wikimedia stats[7] the above distributions cover 98% of the market. The list is for the newest releases, older releases will use older complilers of course. Presumably, the users who stick to these older releases want stability and won't update to bleeding-edge KiCad anyway. Thus I think they are not very important as far as this proposal is concerned. This is why I'm still not concerned. See: http://gcc.gnu.org/gcc-4.8/cxx0x_status.html. Notice the word experimental. Also notice that in order to use C++11 support, the options -std=c++11 or -std=gnu++11 must be used. KiCad builds do not set either of these options so unless you are setting them by environment variable or when running CMake, you are not compiling to C++11. When GCC makes C++11 the default setting, then I'll be a bit more concerned. FYI, GCC does not even default to C++0x which has been a standard for how long? I'm not suggesting that C++11 isn't useful, I just think your jumping the gun by about 10 years given the glacial pace at which C++ language changes actually become the default implementation. C++0x was not a standard ;) It was an evolving draft which one couldn't support non-experimentally. GCC C++11 support is experimental solely because the ABI is not yet stable. That is, using certain standard library features makes a C++11 object incompatible with C++11 objects compiled with different GCC 4.X release. Combining C++11 and C++03 objects is safe regardless of compiler versions, at least that's what the GCC developers say. Note, that core language support is not experimental anymore, as indicated in the announcements on gcc.gnu.org. This means that for a leaf application such as KiCad that uses only C++03 libraries and does not export (at least officially) any symbols taking advantage of a limited set of C++11 features has almost zero chance of causing any problems. By the way, the times of glacial C++ evolution are over. There will be another standard revision next year plus four or five technical specifications documenting various features. One of the more interesting ones is a standard filesystem library based on boost filesystem. If everything goes well, yet another, much larger revision is planned for 2017. Any opinions? In the future, I suggest you refrain from using terms like modern programming practices when trying to convince developers (at least this developer anyway) that the change you are proposing is worthwhile. This is an automatic red flag for me. It sounds like a bunch of marketing hype rather than a well thought out technical argument. While I agree std:: is more readable than using namespaces, there is nothing modern about writing readable code. Good coding practices have been around since good old days of assembly and C. Over the last 25 years, I've seen just about every over hyped new coding technique that was going to radically change the way code was written come and go. In the end, it always comes back to good coding practices. I wanted to write 'modern programming practices' as in 'decade of experience' not as 'a new fad'. It's easily possible to make a list of observations that have led to these practices, but I thought it's better to keep the first email short. I did not intend to say that simply 'newer == better'. Thanks for the suggestion, I'll take notice. Regards, Povilas ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] Renaming Github KiCAD organization from KiCAD to KiCad
I've recently renamed KiCad Github organization to the official name. Anyone who has cloned git repositories hosted there may need to update their local repositories to point to the new location. This may not be always necessary as redirects have been created. Regards, Povilas ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] Removing uses of 'using namespace std'
Modern C++ coding practices discourage the use of 'using namespace std' even in implementation files. Given that C++11 will include a lot of stuff that clashes with functionality in boost, I think it's worth to always explicitly qualify both. I volunteer to do this task in the KiCad codebase. What do the KiCad developers think about this idea? KiCad currently has only 23 uses of 'using namespace std' so the patch won't be large. Regards, Povilas ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Github Library repositories
On 12/01/2013 11:45 PM, Carl Poirier wrote: OK, actually, I had not understood all of the copy-on-write functionality of the GITHUB_PLUGIN, which Dick committed very recently. Some information about it can be read here http://bazaar.launchpad.net/~kicad-testing-committers/kicad/testing/view/head:/pcbnew/github/github_plugin.h#L33. Actually, we would need the repositories to end in .pretty. This will indicate at the same time that it's a pretty library, so no need for a prefix. Looking at the code it seems that only local directories must have the .pretty suffix. There are no requirements on github repository names. In fact, they are not parsed in any way except to build an URL to fetch the contents of a repository. Regards, Povilas ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] bzr is unmaintained. Should we move KiCAD repository to git too?
Just for the record, git has submodules feature, which allows to store external dependencies in-tree and easily manage local patches to them. Regards, Povilas ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Github Library repositories
On 11/30/2013 06:09 PM, Carl Poirier wrote: While doing so, I was thinking that an alternative would have been to create a second organization, named something like KiCAD-Librairies, to host them all and nothing else. In this case, maybe we could get rid of the _lib prefix? I would personally prefer that, so our fp-lib-table is even simpler. If any of you has an objection, please voice in your input. Else, I'll run the script again for this new organization, and hopefully make it the final library emplacement! A prefix ensures that the repository structure is future proof. What if we decided to move symbol library repositories to Github too? This may result in slightly annoying ambiguities in certain usage cases. I think that in this case four characters isn't a big price to pay, especially when most of the library names are longer than 10 characters. By the way, what do you think about 'fp_' as a prefix? It's both more explicit and shorter. Regards, Povilas ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] A proposed improvements for the KiCad project page at Launchpad
Currently the KiCad project page misses several important links. I've added them and reformatted the link list to be more readable. The proposed version is available here: https://launchpad.net/~p12/+archive/lp-playground. Could someone copy the text and paste it to the project page? Note, that the libraries Github link is wrong; it's perhaps better that the entry is removed until a separate Github user for the footprint repositories is created. Regards, Povilas ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] bzr is unmaintained. Should we move KiCAD repository to git too?
Just to inform, bazaar is not actively maintained anymore. The trunk branch, for example, has less than 20 new commits in the past year. A much more comprehensive view about the status of bzr (as of March 2013) can be made by reading the debates in the Emacs internal mailing lists[2]. I'd like to propose to move the KiCad developent to Git and Github, as is being done with the KiCAD component libraries. I volunteer to perform the migration if we decide in favor of it. The switch should be painless: all it takes is a single command to perform migration of entire version history. Local bzr branches can be easily exported to Git without any conflicts too. Arguably, there's not much need to perform the migration now, since bzr is quite mature and there are no bugs interfere with KiCAD development. OTOH, I guess it's still betthatter to keep unmaintained software away from critical duties, especially since the cost of the migration is low. Any opinions? Regards, Povilas [1]: http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/changes Note, that despite unusual name, this is the official trunk branch. See this: https://launchpad.net/bzr/trunk [2]: https://lists.gnu.org/archive/html/emacs-devel/2013-03/msg00776.html ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] bzr is unmaintained. Should we move KiCAD repository to git too?
On 11/27/2013 10:09 PM, Povilas Kanapickas wrote: ... is quite mature and there are no bugs interfere with KiCAD development. ... Sorry for the typos: Should be ... is quite mature and there are no bugs that interfere with KiCAD development. Regards, Povilas ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] bzr is unmaintained. Should we move KiCAD repository to git too?
On 11/27/2013 10:47 PM, Lorenzo Marcantonio wrote: On Wed, Nov 27, 2013 at 10:14:10PM +0200, Povilas Kanapickas wrote: The fact that bzr has so few commits would be in fact a sign that's working fine IMHO :D I believe this is not the case. See [1] and e.g. this post [2]. Please no VCS holy wars, but I don't feel the need for changing system if the current one works... I share your view. I just think that there's high chance that migration away from bzr will happen in the future anyway, thus the proposal. I will unconditionally accept any strong objections. Also what about the pain of a) converting the repo and b) converting all the private repos out there? if it where, like, svn just migrate (if possible without losing a thing) and you are fine. DVCS instead need a way bigger involvement to migrate! Bzr to git migration is very easy. The commands are very similar to the following script: # we are in ../kicad.bzr mkdir ../tmp.git cd ../tmp.git git init --bare bzr fast-export ../kicad.bzr branch | git fast-import mkdir ../kicad.git git clone ../tmp.git # current dir has a git-to-bzr clone The above may contain some errors or typos as I don't have the exact script that I used to convert several other fairly large projects at hand. Thus I believe even private repo migration shouldn't involve more than several minutes of developers time. Regards, Povilas [1]: https://bugs.launchpad.net/bzr/+bugs [2]: https://lists.gnu.org/archive/html/emacs-devel/2013-03/msg00781.html ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] bzr is unmaintained. Should we move KiCAD repository to git too?
On 11/27/2013 11:47 PM, Wayne Stambaugh wrote: I have a strong objection. That makes things clear. Sorry for the spent time. It's not just the repo that would require conversion. The bug list, questions, FAQ, and blueprints would either have be abandoned or migrated to another host such as GitHub unless Launchpad supports GIT. Some projects, such as e.g. QEMU[1], use Github for the main repo and Launchpad for the bug tracker and everything else. Regards, Povilas [1]: https://github.com/qemu/QEMU ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] KiCad symbol and footprint libraries
. This would also make merging easier -- the chance of conflicts and inadvertent duplications would be reduced to a minimum. --- This is all I have to say for now. It would be get some feedback even if my ideas seem silly or conflicting with the current goals -- I'm willing to work on improving KiCad, so it would be great reconcile the difference of opinions from the start :-) Regards, Povilas Kanapickas ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] KiCad symbol and footprint libraries
On 11/25/2013 08:25 PM, Edwin van den Oetelaar wrote: Just for your information, Dick has worked on using Eagle libraries directly. The new eagle libraries are in XML and that makes editing easy. I am going to try to use that function. I already have some projects and footprints (and a full license for eagle version 5 but not 6) and do not want to do the work again. I certainly don't propose the central Kicad repository to be the only possible way to publish your own symbols and footprints. It's only another option. I think that it's perfectly reasonable not to chase the latest formats if there's any kind of migration cost, so we agree here :-) By the way, note that the Farnell Eagle libraries are published under free, as in beer, not free, as in freedom license. This means they can't be used for certain open hardware projects. So it's still useful to have an open source footprint library with a proper license. Regards, Povilas Kanapickas ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] KiCad symbol and footprint libraries
Realisation of it all will just need enormous amount of work and some more than a couple of persons. Searching developers list for library will yield some previous discussions about the subject, also reading kicad-lib-committers [1] archives might be of help. I assume you are talking about main task of creating an extensive, high quality library. If this is the case, I agree with your assessment: doing the extensive and high quality parts is a gigantic task, quite likely out of reach of what we can do in a reasonable timeframe. That's why my ideas in the original post do not try to solve the issue directly: it's hardly possible. Fortunately, we can restate our problem. Too much work is an expression of not enough manpower. There's high chance that the latter can be solved -- after all, every KiCad user is a potential contributor of his own footprints and symbols. What we need is to somehow induce the users to contribute. This can be done by advertising the possibility of contribution and lowering the barrier of entry. The great thing is that both of these are quite within our capabilities. To sum up, what I want to do is to lower the barrier of entry as much as possible, even with short term negative consequences. If I'm successful, I'm pretty sure that it's only a matter of time when we have a central repository we can only dream of now. We should also take this discussion to kicad-lib-committers where it belongs. I'd like to keep it here for now as the discussion involves both the library and the application (new library format). In particular, I'd like to hear what the core KiCad developers think about my ideas. The entire proposal depends on what they say :-) Regards, Povilas Kanapickas ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] Alternative scrolling behavior
Hello, Currently Kicad responds to mouse wheel or touchpad scrolling in the following way: Wheel down -- Zoom out Wheel up -- Zoom in Wheel left -- Scroll left Wheel right -- Scroll right Ctrl + Wheel down -- Scroll right Ctrl + Wheel up -- Scroll left This is quite inconvenient on laptop, where I'm used to touchpad. I'd Kicad to have the following behavior: Wheel down -- Scroll down Wheel up -- Scroll up Wheel left -- Scroll left Wheel right -- Scroll right Ctrl + Wheel down -- Zoom out Ctrl + Wheel up -- Zoom in I think I can implement this change myself. Could someone advice me where to look in the codebase? Are there any hidden dangers (e.g. key/mouse codes being hardcoded all over the place) that would make this task harder than it seems? What do the maintainers think about whether it's worthwhile to have this feature (selectable via a config option) in Kicad? Regards, Povilas Kanapickas ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
