Hi,
I have found a few static variables in the module editor code that I
would like to remove, but I need to know your opinion. The variables are
used to keep the last edited module between editor invocations.
If we want to preserve such behaviour, I will need to add a few more
static variab
On Tue, Jun 10, 2014 at 10:18:57AM +0200, Maciej Sumiński wrote:
> Hi,
>
> I have found a few static variables in the module editor code that I would
> like to remove, but I need to know your opinion. The variables are used to
> keep the last edited module between editor invocations.
Ah these. I
On 06/10/2014 10:26 AM, Lorenzo Marcantonio wrote:
On Tue, Jun 10, 2014 at 10:18:57AM +0200, Maciej Sumiński wrote:
Hi,
I have found a few static variables in the module editor code that I would
like to remove, but I need to know your opinion. The variables are used to
keep the last edited modu
On Tue, Jun 10, 2014 at 11:59:12AM +0200, Maciej Sumiński wrote:
> I see the point of keeping last settings, but should the footprint become a
> new default too? It is much more than e.g. text size, which is common for
> many instances.
I agree that the whole footprint is a little extreme... IMHO
On 06/10/2014 03:18 AM, Maciej Sumiński wrote:
> Hi,
>
> I have found a few static variables in the module editor code that I
> would like to remove, but I need to know your opinion. The variables are
> used to keep the last edited module between editor invocations.
>
> If we want to preserve s
On Tue, Jun 10, 2014 at 08:15:44AM -0500, Dick Hollenbeck wrote:
> I think we need to save that footprint in the PROJECT. Maybe put it there
> upon wxFrame
> destruction, and go get it upon wxFrame creation. That makes it project
> specific.
Wouldn't be better if the footprint were standalone?
On 06/10/2014 08:22 AM, Lorenzo Marcantonio wrote:
> On Tue, Jun 10, 2014 at 08:15:44AM -0500, Dick Hollenbeck wrote:
>> I think we need to save that footprint in the PROJECT. Maybe put it there
>> upon wxFrame
>> destruction, and go get it upon wxFrame creation. That makes it project
>> specif
On 10.06.2014 15:22, Lorenzo Marcantonio wrote:
On Tue, Jun 10, 2014 at 08:15:44AM -0500, Dick Hollenbeck wrote:
I think we need to save that footprint in the PROJECT. Maybe put it there upon
wxFrame
destruction, and go get it upon wxFrame creation. That makes it project
specific.
Wouldn't
On 06/10/2014 08:47 AM, Tomasz Wlostowski wrote:
> On 10.06.2014 15:22, Lorenzo Marcantonio wrote:
>> On Tue, Jun 10, 2014 at 08:15:44AM -0500, Dick Hollenbeck wrote:
>>> I think we need to save that footprint in the PROJECT. Maybe put it there
>>> upon wxFrame
>>> destruction, and go get it upon
On 10.06.2014 16:06, Dick Hollenbeck wrote:
On 06/10/2014 08:47 AM, Tomasz Wlostowski wrote:
On 10.06.2014 15:22, Lorenzo Marcantonio wrote:
On Tue, Jun 10, 2014 at 08:15:44AM -0500, Dick Hollenbeck wrote:
I think we need to save that footprint in the PROJECT. Maybe put it there upon
wxFrame
Hello Javier, Maciej, developers,
We want to thank you for the invitation you have extended to us to
participate in the KiCad development efforts. We agree that there is no
benefit in duplicating the work.
We propose the following to the KiCad interface. Let there be an interface
for Simulation
>
> I clicked send, replying to Lorenzo's comment right when your next
> e-mail came. Sorry for that,
Thanks Tom, apology accepted.
Another thing we get by supporting multiple open projects and paste, is we are
only one
step away (i.e. COPY) from having copy and paste across projects, and the
>
> I wanted paste so I can grab text from a page like this
>
>
> https://raw.githubusercontent.com/KiCad/Transistors_SMD.pretty/master/sc70-6.kicad_mod
>
> or this
>
>
> https://github.com/liftoff-sr/pretty_footprints/blob/master/100-LQFP.kicad_mod
>
> from my browser using the browser'
[giving in to top posting :)]
Hello Oscad Team,
I think it would make sense for us -- and whoever else wants to join
-- to work together on the preparation of a blueprint encompassing all
actions required to make simulation work nicely in KiCad. This would
probably include changes/extensions in f
On 06/10/2014 01:33 AM, Lorenzo Marcantonio wrote:
> On Mon, Jun 09, 2014 at 03:42:23PM -0500, Dick Hollenbeck wrote:
>> You could also create a new constructor that actually takes an int64_t
>> bitmap, and use
>
> For the builtin layers could work, however in general there could be
> more than 6
>> The attached patch will give you an idea of proposed changes.
>>
>> Regards,
>> Orson
>
> We can kill two birds with one stone here.
>
> I like your changes, but they are insufficient to preserve the current
> behaviour. With a
> little bit of work we can accomplish a couple of useful things
On Tue, Jun 10, 2014 at 10:04:36AM -0500, Dick Hollenbeck wrote:
> 1) mask: uint64_t
> 2) index (LAYER_NUM) enum, interchangeable with int in some contexts.
An enum IIRC is always implicitly convertable to an int.
These rules are really nasty, I'll need to try if it accept them. And
anyway I'd wa
On 06/10/2014 06:02 PM, Dick Hollenbeck wrote:
The attached patch will give you an idea of proposed changes.
Regards,
Orson
We can kill two birds with one stone here.
I like your changes, but they are insufficient to preserve the current
behaviour. With a
little bit of work we can accomplis
On Tue, Jun 10, 2014 at 09:06:30AM -0500, Dick Hollenbeck wrote:
> And frankly, if I was going to write a pure library editor, free of project
> roots, then
> I'd do it in python so I could manhandle the library tables. Nothing happens
> without
That's why I said it doesn't feel right to tie th
Hello,
I cannot assign footprints in current Ubuntu release (updated today by
ubuntu).
No components are displayed.
Can you please fix that?
- Michael
Version information:
Application: cvpcb
Version: (2014-jan-25)-product Release build
wxWidgets: Version 2.8.12 (release,Unicode,compiler with
On 06/10/2014 11:41 AM, Maciej Sumiński wrote:
> On 06/10/2014 06:02 PM, Dick Hollenbeck wrote:
The attached patch will give you an idea of proposed changes.
Regards,
Orson
>>>
>>> We can kill two birds with one stone here.
>>>
>>> I like your changes, but they are insufficient
On 06/10/2014 11:31 AM, Lorenzo Marcantonio wrote:
> On Tue, Jun 10, 2014 at 10:04:36AM -0500, Dick Hollenbeck wrote:
>> 1) mask: uint64_t
>> 2) index (LAYER_NUM) enum, interchangeable with int in some contexts.
>
> An enum IIRC is always implicitly convertable to an int.
>
> These rules are real
On 06/10/2014 11:31 AM, Lorenzo Marcantonio wrote:
> On Tue, Jun 10, 2014 at 10:04:36AM -0500, Dick Hollenbeck wrote:
>> 1) mask: uint64_t
>> 2) index (LAYER_NUM) enum, interchangeable with int in some contexts.
>
> An enum IIRC is always implicitly convertable to an int.
>
> These rules are real
<>
>>> I committed class PROJECT::GetRString() and SetRString() in rev. 4934,
>>> paving the way for
>>> saving the MODULE in a session and project specific location and retaining
>>> the current UI
>>> behaviour, while clearing some of the clutter in the path of multiple open
>>> projects.
On 06/10/2014 01:49 PM, Dick Hollenbeck wrote:
> On 06/10/2014 11:31 AM, Lorenzo Marcantonio wrote:
>> On Tue, Jun 10, 2014 at 10:04:36AM -0500, Dick Hollenbeck wrote:
>>> 1) mask: uint64_t
>>> 2) index (LAYER_NUM) enum, interchangeable with int in some contexts.
>>
>> An enum IIRC is always implic
On 6/10/2014 12:41 PM, Maciej Sumiński wrote:
> On 06/10/2014 06:02 PM, Dick Hollenbeck wrote:
The attached patch will give you an idea of proposed changes.
Regards,
Orson
>>>
>>> We can kill two birds with one stone here.
>>>
>>> I like your changes, but they are insufficient t
boiled down a bit more, attached.
#include
#include
//#define __STDC_FORMAT_MACROS
#include
#include
#include
enum LAYER_NUM
{
LAYER_CU_FRONT,
LAYER_CU_1,
LAYER_CU_2,
LAYER_CU_BACK,
};
typedef std::bitset<64> BASE_SET;
class LSET : public BASE_SET
{
public:
static
On Tue, Jun 10, 2014 at 01:49:04PM -0500, Dick Hollenbeck wrote:
> If you back out of your operator | ( LAYER_NUM ), and only use this operator
> with the
> masks, then we might envision a migration path to YOUR objective. The
> objective is "get
> rid of the layer masks". I'm saying we can do
On 06/10/2014 10:29 PM, Dick Hollenbeck wrote:
On 06/10/2014 02:23 PM, Wayne Stambaugh wrote:
On 6/10/2014 12:41 PM, Maciej Sumiński wrote:
On 06/10/2014 06:02 PM, Dick Hollenbeck wrote:
The attached patch will give you an idea of proposed changes.
Regards,
Orson
We can kill two birds with
On Tue, Jun 10, 2014 at 02:22:41PM -0500, Dick Hollenbeck wrote:
> So if we keep it simple, I think the masks can go now in favor of pre-built
> single bit LSETs.
A LAYER_NUM can be implicitly converted to a LSET, so that the idea.
> Have you tried putting all the static constructors in one file
On 06/10/2014 02:23 PM, Wayne Stambaugh wrote:
> On 6/10/2014 12:41 PM, Maciej Sumiński wrote:
>> On 06/10/2014 06:02 PM, Dick Hollenbeck wrote:
> The attached patch will give you an idea of proposed changes.
>
> Regards,
> Orson
We can kill two birds with one stone here.
On Tue, Jun 10, 2014 at 02:51:27PM -0500, Dick Hollenbeck wrote:
> boiled down a bit more, attached.
Would break for more than 64 layers, so a bitset is not needed in the
first place...
--
Lorenzo Marcantonio
Logos Srl
___
Mailing list: https://launch
On Tue, Jun 10, 2014 at 01:27:04PM -0500, Dick Hollenbeck wrote:
> I have voiced my concerns and offered my help. It feels like my help is not
> welcome.
Not at all, as usual you misunderstood. I'm trying you suggestion for
doing an uint64_t constructor (and renamed it to LSET). As expected it
On Tue, Jun 10, 2014 at 08:58:04PM +0200, jp charras wrote:
> when reopening an editor, reopen the latest document(s) previously
> opened makes sense, and moreover is a common feature in many editors.
> My text editor does that, and this feature save a lot of time for me.
> And Kicad too, which reo
On 06/10/2014 04:14 PM, Lorenzo Marcantonio wrote:
> On Tue, Jun 10, 2014 at 08:58:04PM +0200, jp charras wrote:
>> when reopening an editor, reopen the latest document(s) previously
>> opened makes sense, and moreover is a common feature in many editors.
>> My text editor does that, and this featu
On 06/10/2014 04:07 PM, Lorenzo Marcantonio wrote:
> On Tue, Jun 10, 2014 at 02:51:27PM -0500, Dick Hollenbeck wrote:
>> boiled down a bit more, attached.
>
> Would break for more than 64 layers, so a bitset is not needed in the
> first place...
>
Lorenzo,
You are on the cusp of failing, and l
On 10.06.2014 16:40, Dick Hollenbeck wrote:
I clicked send, replying to Lorenzo's comment right when your next
e-mail came. Sorry for that,
Thanks Tom, apology accepted.
Another thing we get by supporting multiple open projects and paste, is we are
only one
step away (i.e. COPY) from having
- Original Message -
> From: Javier Serrano
> To: Oscad Team
> Cc: kan...@iitb.ac.in; "kicad-developers@lists.launchpad.net Developers"
>
> Sent: Wednesday, June 11, 2014 12:55 AM
> Subject: Re: [Kicad-developers] Requesting your co-operation for new version
> of Oscad, a free and ope
On 06/10/2014 04:14 PM, Lorenzo Marcantonio wrote:
> On Tue, Jun 10, 2014 at 08:58:04PM +0200, jp charras wrote:
>> when reopening an editor, reopen the latest document(s) previously
>> opened makes sense, and moreover is a common feature in many editors.
>> My text editor does that, and this featu
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
On 06/10/2014 04:39 PM, Tomasz Wlostowski wrote:
> On 10.06.2014 16:40, Dick Hollenbeck wrote:
>>>
>>> I clicked send, replying to Lorenzo's comment right when your next
>>> e-mail came. Sorry for that,
>>
>>
>> Thanks Tom, apology accepted.
>>
>> Another thing we get by supporting multiple open pr
On Wed, Jun 11, 2014 at 02:19:18AM +0300, Povilas Kanapickas wrote:
> 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 t
On Tue, Jun 10, 2014 at 04:55:10PM -0500, Dick Hollenbeck wrote:
> Lorenzo, please read the modular kicad blueprint. It clearly states that the
> python
> project manager opens more than one project, whereas single top and the C++
> project
> manager have one KIWAY. Each KIWAY has its own PROJE
43 matches
Mail list logo
