I like it that way. But I'm only one person.
On 9/9/2016 11:37 PM, Chris Pavlina wrote:
Along the lines of the version strings - is anyone particularly attached
to having them in the window titles? It's a bit odd, no other
applications seem to do that. I kinda want to take them out, if just to
Chris,
The version in the Window title is great in the project window, so you know how
far from the latest builds your current version is.
On eeschema, there is no version while there is one on pcbnew
so the best would be to keep it on the project window, and remove from the
other windows.
Along the lines of the version strings - is anyone particularly attached
to having them in the window titles? It's a bit odd, no other
applications seem to do that. I kinda want to take them out, if just to
make things a bit more "normal"...
--
Chris
Pushed. :)
On Fri, Sep 09, 2016 at 02:08:52PM -0400, Wayne Stambaugh wrote:
> Have we come to any consensus on this yet? I'm not sure the fake bzr
> revision numbers have any meaning. Git doesn't have any concept of
> linear commits so having a linear number will only make sense when
> building
Good, I ordered a new SSD this week, so it should be here soon. I'll
install MacOS Sierra on there, and rebuild my environment there. I think
it is realistic to have signed packages out by October.
As soon as the SSD is here and I have the OS up and running, I'll jump on
IRC and see if we can
After cirlilo reminded me in the irc today, i think we really need to
get to work on signed osx packages due to the increased number(s) of
osx malware that has been seen in the wild, Including now 2 versions
of transmission have had malware included.
Hows the nightlies coming along adam?
thanks
On 9/9/2016 4:49 PM, Mark Roszko wrote:
>> I'm not opposed to quoting all strings. However the parser still needs
> to differentiate a string versus a keyword such as bold or italic used
> in the font definition. Those should not be quoted. I'm guessing
> you've covered that.
>
>
> Yep, it
>I'm not opposed to quoting all strings. However the parser still needs
to differentiate a string versus a keyword such as bold or italic used
in the font definition. Those should not be quoted. I'm guessing
you've covered that.
Yep, it still has a concept of "keywords" (symbols in sexpr).
On 9/9/2016 3:24 PM, Mark Roszko wrote:
>> I'm assuming this doesn't change the fp-lib-table file formatting.
>
> ~Mostly~ doesn't.
>
> One major difference is I absolutely quote all strings. Right now
> kicad's output formatter does not quote string types if there is only
> a single word. This
>I'm assuming this doesn't change the fp-lib-table file formatting.
~Mostly~ doesn't.
One major difference is I absolutely quote all strings. Right now
kicad's output formatter does not quote string types if there is only
a single word. This violated the sanctity of what was a Symbol vs
String
Have we come to any consensus on this yet? I'm not sure the fake bzr
revision numbers have any meaning. Git doesn't have any concept of
linear commits so having a linear number will only make sense when
building from the master repo. These numbers will not track upstream
for anything built from
Thank you for your patch.
I don't think that it is advisable now. See Roadmap why it is as
(http://ci.kicad-pcb.org/job/kicad-doxygen/ws/Documentation/doxygen/html/v5_road_map.html).
В Пятница, 9 сен. 2016 в 4:48 , Werner Almesberger
написал:
Eldar Khayrullin wrote:
When you zoom back in pcbnew to a 0.37 with the mouse wheel in Legacy
canvas, it stops zooming at 0.37 (zoom level)
but when you go to OpenGL and the do the same thing, PCB disappears! Is
any one else seeing this ?
And one more note the Copy Version info in the help->about KiCad, has no
info
Big kudos to DigiKey, they did a great service to the project!
On Fri, Sep 9, 2016 at 8:21 AM, Wayne Stambaugh wrote:
>
> [1] http://kicad-pcb.org/about/kicad/
>
> On 9/9/2016 9:21 AM, Wayne Stambaugh wrote:
>> For those of you who have not been in the loop, Digi-Key
the existing parser is "by the seat of our pants" style parsing
where there is no centralized parsing logic and instead
manual definition of expected tokens for every single parsable atom
and well, this has led to places where expectRightParenthesis() isn't
called and the like. But that won't
Here, Digi-Key, have some more thanks! :)
On Fri, Sep 09, 2016 at 09:21:17AM -0400, Wayne Stambaugh wrote:
> For those of you who have not been in the loop, Digi-Key Electronics has
> been added to the sponsors list on the KiCad website[1]. They purchased
> the kicad.org domain that was being
Hmm. I took another look at this patch and I'm concerned as to why the
page layout template parser did not choke on this. That should be fixed
as well.
On 9/8/2016 2:56 PM, Werner Almesberger wrote:
> The default and logo page layout templates are missing some opening
> parentheses. Eeschema's
I'm OK with this feature. Anyone object to this?
Ian,
Please change your patch to pass wxEmptyString as the default value for
aSheetLayer. That way you wont have to add wxEmptyString to all of the
DrawWorkSheet calls that don't need it. This should make your patch
touch fewer files.
Thanks,
On 9/7/2016 2:27 PM, Nick Østergaard wrote:
> 2016-03-12 1:37 GMT+01:00 Simon Wells :
>> As part of the translation code rework that i am working on (and
>> auto-detection) part of it is moving the need for changing anything in
>> code to add a new language. As part of this
Eldar Khayrullin wrote:
> Some other issue with space between label and wire:
Yes, text sizing and spacing is one of the darker areas. Eeschema,
Cairo, Pango, and XFig each have own ideas about fonts and how
they are to be rendered, and many details aren't really documented.
If you look at the
For those of you who have not been in the loop, Digi-Key Electronics has
been added to the sponsors list on the KiCad website[1]. They purchased
the kicad.org domain that was being used by it's previous owner to serve
malware and redirected it to kicad-pcb.org. Many thanks to Digi-Key for
their
21 matches
Mail list logo