I was just wondering how many people here use OpenGl canvas for board routing without switching back and forth to the default mode? I made several valiant attempts to give it a try and failed. Every time there would be some silly bug or “feature” that would be just a showstopper for me and attempts to post a bug reports on the launchpads would be met with resistance or simply dismissed out of hand. Just today I figured I’ll give it another try but when I attempted to route a board I noticed that you can’t delete track or vias while using the New Track tool. For that matter you can’t really do anything while that tool is active (no undo, no redo functionality etc) You have to deactivate the tool, do what you need and then, select the tool again. To me that’s just silly. There is no way I’m going to do a layout jumping back and forth like that. An attempt to post a bug at launchpad was met with a brief and taciturn “Won’t fix” response.
Am I missing something fundamental? Some new paradigm shift in the user interface that I’m not grasping?
Default view in KiCad is not perfect but it went through long years of painfully slow progress and now it is finally at least past the growing pains. It seems that with this new CERN development they took everything that has been learned in those years threw it in the trash can and started from scratch.
I’ve been using KiCad from the beginning and I could live with all the corkiness of various features. But this new development seems to be all about the veneer. It is pretty and flashy on the outside but the functionality is just not there. If this is the future of KiCad I think we are all in trouble.
I’ve become dependent on the interactive router so have just gotten used to switching between canvases. I set up a pair of easy to reach hot keys to make the switch back and forth fairly painless and, after several months and a dozen boards or so, it just becomes second nature.
I agree that the need to switch is a pain and it is frustrating that seemingly basic features like deleting a track are not yet implemented (at least in BZR 5365, which has been my go-to build for the last few months).
I would expect that the next stable release would resolve this issue, because otherwise it will fry the noodles of new users. Presumably the long term goal is to port all features over to the new canvas.
Seems to me that the developers had a very good reason to set the bug status to “Won’t Fix”. Also, you might want to reconsider your so-called strategy for motivating the volunteers that keep this project afloat.
Pretend you are in the developer’s shoes. If someone said something like this to you:
As to your sentiment about not respecting the feedback because you’ve got your big boy (hope I’m not being presumptuous here) feelings hurt, that’s just immature. You can accept the feedback based on the merit of the information provided.
Would you be motivated to listen to this person? Keep in mind that KiCad is not your job, it’s a volunteer project that you would possibly be doing for any of the following (non-exhaustive) reasons:
you love the community and interacting with it
you want a tool for your own work that you have control over
you want to leave a legacy
you want to contribute to something that is not profit-oriented
you want to learn about open source and crowd sourced development
I doubt that
you want to receive snide entitled comments about your work
is one of the motivations. Please think have a think about it and familiarize yourself with the existing bug list before adding a new one which duplicates work and confuses things.
Now on to the topic at hand. My limited understanding of the OpenGL canvas existing in its current “unfinished” state is that the push-and-pull router was implemented in OpenGL.
So OpenGL canvas is really just there to give us access to the router now while the developer’s figure out the canvas development roadmap.
I’m assuming that at the moment there is uncertainty about whether to rewrite everything for the OpenGL canvas, or rewrite the router for the default canvas, or put everything in to the Cairo canvas.
The OpenGL canvas is going to replace the old one as soon as all the features are ported - perhaps the next stable release (2016). The future of Cairo is uncertain, it’s just to slow. Either someone optimizes it, writes another software renderer or it gets dropped.
Tom
@Art: don’t expect that the GAL will copy all the behaviours and quirks (e.g. double click to change track width) of the current canvas. Thinks like this keep many professional users away from Kicad…
I am actually only working with the new OpenGL interface and I feel like there is virtually nothing I cannot do there which I can in the legacy UI. Ok, there are some things that are not yet there but it is a work in progress and I really appreciate the speed in which things improve nowadays.
The thing with further-developments is that if everything is supposed to stay as it is, there is no need for changes. Right?
Since this had been on my mind for quite some time but I dont want to start a new topic, does anyone else ‘hate’ the quite horrid anti-aliasing in any one canvas? When I started using the KiCad Librarian, I instantly felt somekind of relief on my eyes from the vastly smoother graphics. Smoother graphics not only look great, but when you’re routing or drawing for hours I’m sure you can avoid strain on your eyes. Anyone else feels the same?
It is not my job to motivate anybody. I’m not a cheerleader. If you signed up to be a developer of KiCad, you ARE a developer of KiCad. Nobody was forcing you in the first place. The fact that you are a volunteer is really irrelevant. Money usually doesn’t change your attitude toward the work you are doing. You either take pride in what you are doing or you don’t regardless if you are paid in dollars or in girly giggles.
However we are off the subject of this thread. I really wanted to see if people find new GAL mode as painful to use as I do or I’m just stuck in my old ways and can’t see how it is an improvement.
[quote=“Airic, post:6, topic:1262”]
I am actually only working with the new OpenGL interface and I feel like there is virtually nothing I cannot do there which I can in the legacy UI.
[/quote] To me it is not really a subject of weather you can do it or not but how painful it is to get it done. Do you really switch back and forth from track tool to regular cursor to delete a track or undo a change or is it just me not being able to find the trick? I just wasn’t able to get over that (thus is the “offensive” statement that it made it unusable for me) No push and pull is going to be worth the pain.
[quote=“Airic, post:6, topic:1262”]
The thing with further-developments is that if everything is supposed to stay as it is, there is no need for changes. Right?
[/quote] I’m all for changes. I like pretty graphics as much as the next guy. But if the price of pretty facade is that all the hard learned features get dumped in the process, then I’d rather have ugly graphics with a functional tool. I can understand growing pains and bugs associated with it. But KiCad has been around for probably close to ten years right? So you are not starting from scratch. At least you shouldn’t be. I however don’t get the feeling that this “future” of KiCad is utilizing all that has been learned so far. Obstinate developers certainly don’t help the matters.
I am missing the “delete complete track” feature as well. This is not yet implemented or a bug in the current OpenGL mode. My solution to this is simply deleting the segments. It’s just pressing the “DEL” key 3 to 4 times and this is way faster than switching back and forth. Anyways - for me the advantages of the new mode outrace the legacy UI quite a bit.
better graphics
much much faster panning and zooming (!!!)
graphical element can finally be moved and aligned to the grid (nice for more complex outlines)
push and shove routing
pair routing
…
Things are being implemented and continuously further developed for you for free! Don’t forget that. I too think that the way we communicate things has a great impact on if the message is received or not. This forum is a great way of contributing to the software by posting your thoughts and recommendations. I am hosting an open-source project as well (minie.airiclenz.com for those interested) and I know how different types of feedback feel and whom I am more willing to help
Try to hover the mouse cursor over a track and press U (select trivial connection) or I (select copper connection), or use the right-click context menu to pick Select->trivial/copper connection.
I’m getting a distinct feeling that I’m really missing something here. For me Delete function (or Undo or Redo and who knows how many others) dont’s work when the New Track tool is active. So if you just placed a new track and need to undo or delete it you have to deactivate the NewTrack tool (hit Esc), the cursor will change from cross hairs to regular, only then I can delete or undo and then if I want to continiue I have to press the New Track tool button again. So you either know something I don’t or you are much more tolerant to annoying repetitive actions.
Then press the button (or a shortcut) to go back to routing - that IS switching back and forth Am I the only one who finds it too cumbersome to use? Imagine you had to press several “shortcuts” in MS Word before you could erase what you just typed and then press another shortcut to go back to typing.
With all the love I have for KiCad, I strongly agree with ArtG that this logic is convoluted and should be fixed.
the same applies to context menus.
It took me ages to figure out, that I had to exit the fill zone tool to get access to the command to actually fill a zone. Why?!?
The same goes for the properties and remove commands not being available in the track context menu while adding tracks, or access to footprint commands and properties (or any menu) while placing components.
I wouldn’t call the behavior of menus on the legacy canvas a “quirk”. Is there a reason why the context menu logic can’t be carried over 1:1 from the legacy canvas?
One of KiCad’s strength is/was that the basic functionality is quite intuitive to discover and use. While the OpenGL Canvas is very functional and the more powerful routing is very welcome, it is a big step backwards in general usability.
Just started to switch to KiCad and tried to reproduce the stuff shown in the push & shove video. Things noticed immediately:
OpenGL mode requires OpenGL 2.1, which my (low end, but perfectly suitable) graphics doesn’t support. Switching to OpenGL is simply denied. A workaround is to start the application with forced software rendering, which can be done from the command line, only.
With OpenGL enabled, the mouse pointer jumps around in some situations, disconnecting it from the mouse. Apparently intentional jumps, like the pointer jumping to the canvas center on zooming with the mouse wheel. Disconnecting the mouse pointer from the mouse is IMHO a big NO-GO. The standard canvas appears to work fine in this regard.
Moving tracks appears to be impossible. The video says to ctrl-click. Doing so, nothing happens, moving the mouse has no effect. In standard mode I can move tracks, if only one segment at a time.
All this with binaries compiled from Gi…,pardon, BZR as of yesterday on Ubuntu 15.04.
Other than that, yes, these three modes (highlight, shove, walk around) are very nice and useful.
With such a behaviour KiCad is certainly unique and not in alignment with Gtk, Windows or OS X guidelines. And I hear the “it’s more powerful” calls already. Which usually means “I’m used to it” …
In between I also found that the jumping cursor can be turned off in preferences, at least for jumps during zooming.
I use KiCAD only in OpenGL mode. The last functions because of I had to switch back to default canvas often was “Highlite net” and Design Rule Checking. Both arrived to OpenGL somewhere in July or Aug 2015. Since then I never go back to canvas mode!!
OpenGL 2.1 was published in 2006. Is it too much to require that your hardware should support a 9 year-old standard?
I fully agree, however, with the fallback to the software renderer, we’ll fix it.
There are multiple ways to interactively drag traces:
select routing tool, hover the cursor over a track or via and press ‘D’ - the default shortcut for Drag function.
select ‘drag trace’ in the R-click context menu
ctrl-click also works when the router tool is active
There is also an option to make interactive dragging as the default behavior (instead of moving the segment). Open the Preferences->Interactive Routing dialog and choose “Mouse drag behaviour: interactive drag”. It’s disabled by default because some old users complained that it breaks their workflows (“I’m used to …”).
Same applies to the jumping cursor issue, certain users demanded that the GL view should center the window on zoom. It can be disabled in the General Options dialog.
Am I the only one who finds it too cumbersome to use? Imagine you had to press several “shortcuts” in MS Word before you could erase what you just typed and then press another shortcut to go back to typing.