Gaurav asked for examples using Qt: Eagle.
As they implemented their awkward UI across all OS, I see no problems
whatsoever for Kicad.
Having done multiplatform / multiarchitecture releases with Qt, I can confirm
it was totally stable and automatized.
Wayne is correct, a huge amount of effort w
Bernhard,
Please file a bug report(s) so we know about the issue(s) and fix them.
They tend to get lost in the dev mailing list noise. I haven't used the
new symbol table view at all other than so initial testing so I suspect
there are some bugs in there. Hopefully the developer who did the
orig
Hi,
a bit of topic, but just out of curiosity… I tried to use “Component Table
View” of eeschema recently in one of my projects - on macOS of course.
Nice to have a look at the parts, but apart from that not usable at all.
Most of the time I cannot enter something into the grid cells, I have to
Perhaps to help prevent the discussion bubbling up unbidden every few
months, we should create a document which formalises:
1. Gripes or difficulties with wx
2. Features we would require in some hypothetical GUI toolkit
3. Pros/cons of each toolkit
This document could be updated as we discover ne
Hi all,
>
> I wondered when this subject would rear it's ugly head again. Every
> couple of years we dig this horse up and beat it to death again. It's
> getting rather comical. Like JP, I would like to see some proof of all
> the wonderful things QT can do for us that wx cannot. It has been
I haven't had any complaints yet, just want to make sure everyone knows
there is basically only one way you can do it that works well.
On Dec 4, 2017 13:21, "Maciej Suminski" wrote:
> Hi Chris,
>
> I suppose I am the main wrestler and as far as I can tell,
> wxDataViewCtrl tree works very differ
Hi Chris,
I suppose I am the main wrestler and as far as I can tell,
wxDataViewCtrl tree works very differently on each platform. I tried to
implement dynamic updates, then have jumped through numerous
wxRingsOfFire and in the end I have returned to your approach. It should
works as fast as in the
I really hope the original point of the thread is not lost in the 53rd
boring repeat of this argument. PLEASE test COMPONENT_TREE on macOS, I
don't want to have to fix it myself if it's slow again.
On Mon, Dec 04, 2017 at 07:44:19PM +, Wayne Stambaugh wrote:
> On 12/4/2017 1:47 PM, jp charras
On 12/4/2017 1:47 PM, jp charras wrote:
> Le 04/12/2017 à 18:53, Tomasz Wlostowski a écrit :
>> On 04/12/17 18:48, Chris Pavlina wrote:
>>> Hey, just a comment because I see people are wrestling with
>>> COMPONENT_TREE performance as I did when writing it. TEST ON MACOS. The
>>> performance of the
Le 04/12/2017 à 18:53, Tomasz Wlostowski a écrit :
> On 04/12/17 18:48, Chris Pavlina wrote:
>> Hey, just a comment because I see people are wrestling with
>> COMPONENT_TREE performance as I did when writing it. TEST ON MACOS. The
>> performance of the widget there has a really different profile fr
Yes, so we could perhaps extend this to cover the other common areas where
we use the UI toolkit for non-UI things (mostly OS interaction, I guess),
although at some point it becomes about more than just tools, so the name
might be confusing.
On Mon, Dec 4, 2017 at 1:28 PM, Tomasz Wlostowski wrot
On 04/12/17 19:23, Jon Evans wrote:
> It's probably a good idea to implement a "toolkit abstraction layer" if
> we ever go down this road, so that we wouldn't have to do it *again* if
> we ever switch again.
This is the very purpose of the internal event system (TOOL_EVENT,
TOOL_ACTION, TOOL_DISPA
I think the huge amount of programming effort is the main roadblock, but
maybe Wayne et. al. have other thoughts.
The roadmap might look something like this:
1) Enable printing without wx (using cairo)
2) Finish porting any remaining features to GAL for PcbNew and GerbView ->
Remove legacy canvas
What are the roadblocks besides the huge amount of programming effort
required for this? Im on linux and I would like this as well.
- Kristoffer
On 2017-12-04 19:09, Bernhard Stegmaier wrote:
On 4. Dec 2017, at 18:55, Chris Pavlina wrote:
On Mon, Dec 04, 2017 at 05:53:12PM +, Tomasz Wlo
> On 4. Dec 2017, at 18:55, Chris Pavlina wrote:
>
> On Mon, Dec 04, 2017 at 05:53:12PM +, Tomasz Wlostowski wrote:
>> On 04/12/17 18:48, Chris Pavlina wrote:
>>> Hey, just a comment because I see people are wrestling with
>>> COMPONENT_TREE performance as I did when writing it. TEST ON MACO
On 04/12/17 18:59, Jon Evans wrote:
> I've got some experience with Qt and would be willing to help out with
> investigating this at some point. My only experience with wx is with
> kicad, and it seems to have many more problems than Qt...
> On the other hand, I disagree with the suggestion that
I've got some experience with Qt and would be willing to help out with
investigating this at some point. My only experience with wx is with
kicad, and it seems to have many more problems than Qt...
On the other hand, I disagree with the suggestion that Electron would be a
good path for KiCad, eve
On Mon, Dec 04, 2017 at 05:53:12PM +, Tomasz Wlostowski wrote:
> On 04/12/17 18:48, Chris Pavlina wrote:
> > Hey, just a comment because I see people are wrestling with
> > COMPONENT_TREE performance as I did when writing it. TEST ON MACOS. The
> > performance of the widget there has a really d
On 04/12/17 18:48, Chris Pavlina wrote:
> Hey, just a comment because I see people are wrestling with
> COMPONENT_TREE performance as I did when writing it. TEST ON MACOS. The
> performance of the widget there has a really different profile from on
> other systems. I had to do things in really unob
Hey, just a comment because I see people are wrestling with
COMPONENT_TREE performance as I did when writing it. TEST ON MACOS. The
performance of the widget there has a really different profile from on
other systems. I had to do things in really unobvious ways to make it
perform reasonably there.
20 matches
Mail list logo
