It doesn’t matter when the standard was published, it matters which hardware supports it. My PC is certainly not 9 years old, still it supports only OpenGL 1.4.
I suspect your video hardware might be perfectly compatible with OpenGL 2.1 but your current video drivers might not support it.
Any cheap 30€ nvidia card does openGL 4.X - at least on linux.
I second madworm’s reply. If you choose to use Linux, buy an Nvidia card and install the proprietary NVIDIA driver. If you’re a developer, help the people in charge of the driver you’re using to implement new GL features.
Tom
Certainly not, I looked it up.
Closed source software? You’re kidding : - )
Right. One can “just buy” such a card. Provided one has a PC which allows to do so (Laptops? Tablets? RaspberryPis? qemu?) and a particular user has the expertise to install this card (which 90% of computer users don’t have).
That’s not the problem. The problem is that all other applications do not require additional hardware. Catia, gEDA, Eagle, Blender, FreeCAD, SolidWorks, whatever you try, it just works. In such an environment people are simply not used to install hardware for specific applications. They wouldn’t even shut down the PC to give KiCad a try, much less open the case.
Applications requiring custom hardware mostly disappeared some 20 years ago for good reason: each time it doesn’t fit means a lost user. Drawing a PCB means drawing a few thousand lines and regarding computing that’s not exactly much. Rendering a page of text is more demanding.
From the programmer’s view it’s also good practice to keep compatibility with the most low end hardware. Low end hardware demands effective use of algorithms, which is something everybody benefits from. It also demands proper abstraction of modules and classes to get more than one renderer (software, hardware) working. Again a benefit for everybody. Not to forget that this low end hardware already works, just not with these new functions. Apparently some abstraction is not yet done.
That said, cheers to you that everybody here is capable to install hardware. I have a number of DRAM sticks already bought, waiting to be installed, since … I think 3 years : - )
KiCad runs fine on my 10 year old laptop. It has a crappy Intel 945GM graphics chip. It runs openGL apps just fine.
Discussion took a weird turn. I would be all for discussing some nuanses of the software if the basic functions would work properly.
[quote=“novaktamas, post:19, topic:1262”]
I use KiCAD only in OpenGL mode
[/quote] I personally can’t route a board, when every time I need to delete a track I need to switch to a different mode. I mean I can but I’m not gonna as long as I have an option of using default mode (which might be not for very long) May be you just never make mistakes?
[quote=“novaktamas, post:19, topic:1262”]
The last functions because of I had to switch back to default canvas often was “Highlite net” and Design Rule Checking.
[/quote] Not to be a glass half empty kind of guy, but “Highlight net” doesn’t function properly either. In high contrast mode with zones filled you will never see the whole net highlighted, just what is visible on the current layer.
That is my biggest beef with this OpenGL doohickey which is unfortunately to become the only KiCad in the future. Instead of building on hard earned lessons of KiCad they decided to start from scratch and redo the whole interface. It might be fast (which I personally never thought that KiCad was slow) but usability really tanked.
I’m not an experienced Kicad user, but my only complaint with opengl mode is that on my 4k monitor the grid points are nearly invisible.
@ArtG, you are right at most of things…but you probably missed the “U” and “I” multiple select keystrokes (+Del button) for deleting full tracks. This is why you DON’T have to switch back to canvas.
I didn’t miss anything. “U” and “I” shortcuts (which respectively a whole track highlight
and a whole net highlight) work only when you exit track drawing mode. That is not to mention the fact that more often than not you just need to delete the last leg of the track that you’ve just drawn (which you can conveniently do in the default mode by pressing backspace key) and continue drawing tracks without ever changing the mode.
To me personally OpenGl mode is like Dodge Viper - it’s all flash and raw power but very little though put into smart engineering, functionality or usability.
There is an interesting read here on the UI improvements that may be considered in the future. It is explained there that for instance this behavior of not being able to delete a track while drawing tracks was implemented on purpose 0_0 They were trying to copy behavior or Corel Draw and some other vector and raster graphics editors, when you have to select a separate tool for each action. That is the problem when people who design stuff not only completely disregard KiCad legacy (but rather use it as a byword calling condescendingly the “old” and “outdated” mode) but also don’t have firsthand experience with other EDA software packages. In case like that they start copying features of the software packages they are familiar with, which happens to be in this case a graphics editor.
1 Like
Yes, indeed an interesting read. Still only the opinion of 2 or 3 persons. Regarding entering this discussion I got this answer (on the developer list):
That’s not exactly what I understand by “discussing” a topic, so I take we have to leave the UI design to the CERN folks.
Copying from a graphics editor isn’t the worst idea. For one it’s attractive to newbies, because they’re likely used to graphics editors already. The other one is: at the bottom line a PCB layout is, well, just a graphics and pcbnew a beefed up graphics editor.
I really like the openGL mode and can put up with most unimplemented features except for one - press DEL to delete a track that the mouse is hovering over while in track creation mode. Would make manual routing a lot faster. Apart from that I appreciate the push and shove feature which saves a lot of time with the more complex boards.
I think that basic functions DO work. I’ve changed to KiCAD a year ago, when I had a job with a FPC connector in angle (not even 45 degree, but ~25 deg) and my previous PCB designer couldn’t do it.
I successfully have finished abt 10 projects in KiCAD by now. There was(is:)) a learning curve, and there are a lot of inconsistent, not-ready-yet, would-be-better things even now, but it IS usable.
If you are perfectionist and little unpatient then KiCAD (or any other community opensource) is not for you. Buy a legal Altium or PADS or ORCAD rather. They are not flawless, but really closer to be ready than KiCAD.
I fully agree - please don’t forget that this is a free-of-any-charge CAD tool which is under heavy development and is being improved all the time.
You are not really throwing in RaspberryPis and Tablets (assuming touch-only version) as CAD development platforms, are you? I agree on the fact that there should be a as broad as possible support for different hardware- and OS-versions but there should be (logical) limits. As far as I know, the RaspberryPi is capable of running KiCAD but please don’t ask for a smooth workflow and support of all (higher-end) features of KiCAD.
To be honest, I still don’t see this as this kind of problem that makes it - as you call it - impossible to route a board. Pressing ESC just takes a fraction of a second and then you can just go ahead an delete the track. Pressing X and you are back in. If you really feel like this is a no-go solution then maybe you should consider contributing to the code and provide an alternative option.
Sometimes I get the impression that some people can’t think in other terms that 8 layer boards and 1000+ pin footprints. “It can’t be right if it’s easy to learn, simple to use and runs everywhere” or similar.
Simple stuff has to be done, too. For example boards like this: http://reprap.org/wiki/Gen7_Endstop_1.3.1. I see zero reason to artifically limit usability of KiCad to expensive hardware. The lower the hardware requirements, the wider the user base and the faster it runs on fast hardware.
I was not saying that the RaspberryPi is not, or should not be working with KiCAD. I was just mentioning that it is not one of the platforms that allows quick and fluent PCB design as it is a pretty low end computer. I am not sure if one can really expect it to support all OpenGL functions that KiCAD may require…
opengl 2.1 hardware is not expensive and if you can’t afford it, stay with the canvas mode for the time being?
It’s a 9 year old standard… we’re not talking bleeding edge here.
IMHO: anyone who does KiCAD on 1 screen under 20" is a masochist anyway.
PS: I’m on canvas mode still on BZR6097 on 2x 22" 1680x1050 lcd screens from 2009. Would def not go any smaller.
It is. The premise of the two is completely different. While one is a precise engineering tool, the other doesn’t really care if you are off by several pixels or the color gradation in not exactly on the number. Imagine you text editor would require you to exit the “typing” mode before you could delete what you just typed and then you would have to re-enter the “typing mode” again. And yes it is a pain in the butt to press two buttons constantly to switch back in forth. Multiply those presses by how many times you delete tracks and vias in a big design and you will get hours of you sitting there pushing two buttons like a moron for no particular reason.
I like it as much as the next guy an attemp of somebody who just started to use the software to teach somebody who was using it for almost ten years now what is for me and what is not. I used the program through all its growing pains and had to go through those pains to see it get better. Now I see the developers getting alzheimer’s and completely forgetting what has been learned in those years and going for hipster revamping of sorts.
“You should contribute instead of complaining” argument is a moot point in this case since the developer in charge already stated that this behavior has been implemented on purpose. Besides everybody got their roles to play: some write code and some test it and provide feedback.
it’s definitely not nice to need to exit/re-enter the track tool if you want to go back one segment of the track while you’re putting it down.
Also the space between the [DEL] and [X] key on the keyboard don’t make this a very convenient option for button mashing.
So put me down for wishing the [Backspace] functionality being available within the active track tool for OpenGL.