It looks like you're new here. If you want to get involved, click one of these buttons!
I continue to be impressed by this software. A few miscellaneous observations or questions (I'm running 0.23 on Windows 7):
When you add a shortcut key from a menu item, if there is already an existing use for that shortcut key, then I typically find that both functions cease to work. For instance if you write a script and assign it Ctrl-B then not only does your current script not run with Ctrl-B but also the original binding for Ctrl-B (which happens to be "Duplicate selected object" fails to work. Right now my workaround is to first do File > Setup > Key bindings, and scroll down the list to find a shortcut key not in use, then using it for the Ruby script I'm writing. I suggest it would be preferable for the script to generate a warning or error at runtime if you try to assign a key that's already in use..
When you use Ruby to remove a shortcut key from an existing key binding (by assigning it "") or to replace a shortcut key by overwriting it with another one, the changes are not reflected in the list found at File > Setup > Key Bindings.
I love this program and want to help others to not have a hard time learning how to write macros. I have a bunch of scripts I'd like to share. At worst these would be example scripts others could learn from but may not use directly. At best these would be nicely commented and robust tools that others can actually use, as-is, in their daily work flow. I think or hope others in the community would also want to contribute. I could post each one as a Forum post, but then they get lost in the other posts. Are there any plans for a sort of "Matlab File Exchange"-type of community website where anyone can post scripts along with descriptions and example usages (and going further, eventually user comments, ratings, etc)? I think this would be a valuable tool, but am aware it is a lot of work to set up on your website. Do you have any other suggestions for how I can make my scripts publicly accessible and easy to find or stumble upon and therefore useful for others both in learning and production stages?
In an old forum post, someone mentioned you are working on a 3d software, but I find no links online with a quick Google search. Is this public yet and do you wish to share a link? I'd be very interested in what else you've come up with.
I think the following may be a Windows thing. When I have Macro Editor open, say I select a polygon and then run a script via a shortcut key or a toolbar or menu item. Then the window focus shifts immediately back to the Macro Editor, regardless of whether that particular script is open in the macro editor or not. This is mildly annoying as it disrupts workflow (for instance if you want to press a second shortcut key immediately after the first, then the second key will get sent to the Macro editor rather than to KLayout proper. Of course I could just close the Macro Editor window, but I often need to be editing a macro and then intermittently doing other KLayout functions as part of the testing procedure etc. Or sometimes it's just more convenient to leave both Windows open (I understand this means all my scripts run slower, but most scripts are small and this isn't noticeable). So I'd suggest if there is any way to change it so Macro Editor window didn't take focus each time any script is run (but it can maintain focus if it already had focus) then that would be preferable.
Related to the previous one, there is a far bigger problem on Windows (I haven't tried it on Linux so can't comment on that). When you have Macro editor open and you open any other KLayout dialog (for instance, you have macro editor open, then you click to select a shape in the layout, and choose "move by" in the Edit menu) then it goes wack-o. The two windows (the main KLayout window and the Macro window) flicker really quickly like they are both trying to get focus and are rapidly flicking back and forth between the two. At any rate, both windows and the dialog box become unresponsive. If you try to click on either window during this period of confusion, windows takes over and tries to help - Windows greys out both windows and says "This program is unresponsive. Would you like to wait, kill it, or cancel this helpful dialog?" Sometimes it resolves itself if you wait but it usually takes 60 seconds of flickering, while other times it doesn't resolve within my patience limit and so I have to kill KLayout in Windows Task Manager.
In practice I get around this by just never doing any KLayout functions that require a dialog box, while I have Macro Editor open (so if I want to "move by" then I close Macro Editor, do the "move by", then re-open the macro editor) but it's mildly annoying. Again I assume that this is just due to how Windows chooses what window is in focus, and Windows may be having an argument with itself. I could be wrong there though - that is just an assumption.
I am frankly amazed that as far as I can tell, you wrote and maintain all this software single-handedly. I would be really interested to know your story and how or why Klayout came to be, perhaps you could share a short version here or on the About page..
There is no rush on the replies, I understand I've given quite a lot to chew on up there.
.8. I understand rb and lym files and the difference and when to use one or the other. Yet I notice often when you write a tool (like xsection) you make it an rbm file. I can't seem to understand why, or when I should be using rbm, or what advantages or disadvantages it supplies. The website doesn't say much about these. I these seem to be when you want a standalone tool that is simple to install (just plonk it down somewhere on KLayout's path).. But you can do that with lym file too, right (though of course lym file is slightly less readable if viewed with a Notepad program. Anyway, when (if ever) should I use rbm and what are the considerations for using that?
thanks for that awesome lot of input :-)
Here are my comments:
1.) this is handled by Qt ... I agree that's not a nice behaviour and I'll try to figure out whether that is possible.
2.) I'm not aware of this. Basically there are different sources of events (menus, macro bindings, Qt shortcuts ...) and hence shortcuts may not be reflected from one source into another. That's a little messed up and I'm not sure I can fix all interactions. But that aligns well with 1.) and I'll put it on my list.
3.) Very good idea, indeed. I though of this and actually, my scripts are already in a semi-public SVN respository. What is lacking currently is a good deployment and installation mechanism. Plus maybe package dependency resolution. I started a decent Ruby scripting project at SourceForge (XSection@KLayout), which is one way to publish applications atop of KLayout. But again, without a good deployment. BTW: I have recently added a lot of documentation there in case you're interested.
4.) No, not really. At least not right now. There was some suggestion to provide depth information as well. One output is the cross section project just mentioned.
5.) I have to check this. In general the macro editor comes alive whenever a Ruby statement is executed in order to catch breakpoints and allow to break execution. Maybe that shifts the focus too. It also slows down execution. If you close the macro editor (temporarily), that will also improve execution speed.
6.) I'm sure that is related to 5.). I have not observed that yet, but frankly, I'm mainly working on Linux. It's likely I did not come across that yet. It's on my list already.
7.) Well, single-handedly might not be the right word here ... Some stuff is hard work, some is easy, but as long as it's fun, there are no limits :-) I wish I could share a story about Cowboy programming and beer-loaded hacking contests. But reality is somewhat boring. The origin was a kind of programming competition between some software developers in Munich (and there in fact is a connection with beer). Later my motivation was dissatisfaction with the tools I had to work with. Then there was the crisis of 2008 that brought down the company down for which I was working at that time. That gave me spare time for more development and now I'm mainly carried by the encouraging feedback I receive ... But maybe I'll stay with the hacker story and put that on the About page :-)
8.) Ok .. needs explanation, you're right. It's simply evolution. rb was first, rbm came later as a way to load (and not execute) Ruby code and finally I created lym in order to wrap up the code with meta information and provide some basis for alternative languages. Macro binding to menus or keys can be done by configuration in lym instead of coding and lym also provides a way to select DSL's (like for DRC). xsection is rbm for historical reasons, but I can be put on lym as well. rb and rbm still have some justification because when you load or require ruby code in other ruby scripts, you cannot use lym. Plus, with lym you'll have to use the macro editor (unless you what to write "if a < b") and if you don't like that, you can still use rb or rbm. Installation-wise there you can both install rbm and lym easily by drag and drop (recently directly from the web link). rb won't install, it will execute.
Hope that balances the effort you spent for your comment. Thanks a lot.
Wow fantastic (and fast!) reply, thanks.
1 & 2 : Thanks
3 : There may be some kind of open-source script repository out there, that would be easy to integrate with a website such as this (so, it'd be found at klayout.de, not at some other website). I'll dig a little.
4 : OK, never mind.
5 & 6 : Yes I guess this is the biggest problem I face today. It can be worked around by closing the macro editor when not using it, but it may be a turn-off for newcomers if they don't understand. Understood that you probably never encountered this before since you use Linux.
7 : Interesting! Thanks. OK but still you have done a great work and apparently mostly or entirely by yourself. I have found the scripting incredibly powerful and easy, and am probably never going back to other proprietary software...
8 : OK I understand. If you are interested, I almost never write my scripts as .lym. I almost always write them as .rb, so they can be freely called by each other. The only exception is a couple of my scripts that must run on startup - those are .lym. Perhaps in the future a way to call .lym scripts from other .lym scripts could be useful. Not highest priority though.
Also just a general note: I have found the scripting functions (thus, layout editing via scripts) to be very useful. And I also draw via the GUI a lot. (Though, I have added a lot of customizations and keyboard shortcuts to speed that up.)
Yet I get the impression from certain places that this is primarily a layout viewer and secondarily a layout editor. For example the pdf user manual for version 0.21 starts out saying essentially that. My guess is that it used to be primarily a viewer, and more recently you have added more and more editing functions.
Also I have mentioned to several people that I use KLayout for scripting and general layout/drawing, and several people have replied "Really? You can edit on it? I thought that was just for viewing layouts." Of course, you have the dialog on startup to tell them about editing mode, but still my limited impression is that most people still don't get it. And when they do they are keen to try editing on it. Anyway I suggest as this becomes a more powerful editor that you try to dispel that notion and tout it as more of an editor than a viewer.
Anyway I hope that general comment helps some way. Great job again
thank you for your comments.
The 0.21 PDF manual was contributed by a user and I really appreciated his work, so I put that on the server. Frankly, it got a little outdated, because I was working on the online documentation that time and I did not have time to synchronize both.
You're right - it started as a viewer and piece by piece, editing functions have been added. There is a technical reason for keeping both modes - the internal data structures are more compact in the viewer mode, specifically when representing OASIS shape arrays. That's important for users loading multi-gigabyte files, so I kept that.
On Windows, there are several entries in the Start menu, so it's possible to chose which mode to use. On Linux there is no general installation procedure yet, so it's hard to control that feature.
The reason why I did not advertise the editor mode too loudly was that I was suspecting that would rise a lot of expectations and a lot of requested features are still missing. Once it grows further, editing will be a more pronounced feature and in the end I might as well provide two separate binaries to emphasize the presence of an editor.
And I like the script repository idea a lot ... I am investigating the technical options for that.
Sorry for bumping this thread, but I am struggling with the same issues as David regarding the Macro Development window "stealing the focus" from the main KLayout window. I am mainly running KLayout under Windows 7 but recently also built it on a Ubuntu virtual machine.
Especially when doing Qt GUI development, but also when editing a GDS file, I find it counter-intuitive to have to close the Macro Development window if I want to do anything in the main window other than clicking. For example, pressing M to activate the Move mode in the main window sends the M key to the Macro Development window instead if it is open.
Sometimes clicking on GUI elements (added by my script) or even buttons in dialogs (such as the one from the Qt Binding example) does not work reliably while the Macro Development window is open. I also recall that sometimes I had to use the keyboard to close dialogs opened by the Macro Development window itself because of the "focus fight" between the dialog and the Macro Development window.
While I have seen (again, under Windows) other programs having "always on top" windows, they are less "aggressive" than the Macro Development window in that they stay on top of other windows but without actually taking the focus - which makes them behave just like windows in the background in that they don't interfere with whatever I am doing elsewhere.
I have tested the behaviour on both Ubuntu 14.04 and Windows 7, with both KLayout versions 0.23.10 and 0.23.9.
Since you said earlier that this is a windows-only problem, I am starting to wonder if it is a more general Qt issue - which specific Linux operating system are you using where it doesn't have these problems with the "stolen focus"?
Did you observe any issues on Ubuntu 14.04?
I never managed to pin down the issue. (I am the David from the original post.) I installed on another Win7 machine and the problem went away. Since then I don't use that computer but installed on yet another Win7 machine and have the problem again. I haven't been systematic in what I try though, so I will try a few more things and report if I find the source of the issue.
Yes, I have the same "stolen focus" problems on Ubuntu 14.04.
That is why I think it might have something to do with the specific way Qt handles "always on top" windows. But maybe it is just the way KLayout uses Qt. Ideally, I'd prefer to have the Macro Development window just behave as a normal window with "equal rights" as the KLayout main window. But I guess we need Matthias for that :-)
It would be interesting to know which platform he's running KLayout on, since he doesn't seem to have this issue.
Maybe it is dependent on (graphics) timing/performance?
Hi both of you :-)
I'm running Ubuntu 12.06LTS right now (I will surely switch to 14.x sooner or later). There should not be a big difference, 12.06LTS is well maintained and the Qt version is quite a recent one.
Actually, the Macro Editor Window is not special. In fact it's a normal main window.
BUT there is one difference: when ANY piece of Ruby code is executed, the main window gets notified and may even become active (that's probably what you observe as "agressive"). That is because it receives special event handling during execution of Ruby code because only this way you are able to trigger breakpoints and single-step through code. That involves bringing itself to the front (in particular in the case of the breakpoint or an error), but I'm not aware that this also happens under normal run conditions.
I can try to have a look at the code.
I see. I think you are right but will try a few more things to see if I can isolate the issue.
A simple fix for the meantime would be to have a toggle button in the Macro Editor that disables the breakpoints. As for me, I have only used breakpoints a handful of times anyway.
Thanks for looking into this.
While investigating, I have found at least one reason for the focus issue: In my setup, there was a LYM file which started a QTimer automatically in the background at startup, running code repeatedly to update the main window's title bar - it is actually the
UpdateTitlemacro on this forum.
Removing this has improved the behaviour of the Macro Development window significantly, although I am a bit surprised that code just running in the background causes a "focus grab".
There is another reason for "stolen focus" which I came across, would be interesting if it behaves the same for you:
As you can see, it simply creates a
QDockWidgetwith a button. Since I am rather new to the Qt binding, I might have made a silly mistake - can you confirm that this should work?
Under Windows 7, when the Macro Development window is open, I am unable to click the button or do anything else with the main window, such as clicking menus or resizing it. I always have to close the Macro Development window before testing the GUI.
Unfortunately I am having trouble with my Ubuntu VM at the moment, which is why I couldn't test if it behaves the same there - will let you know once I'm up and running again.
Just tried this again on KLayout 0.23.10 under my Ubuntu VM and there, the dock sometimes prevents the button on the
QDockWidgetto be clicked and the focus always goes to the Macro Development window after clicking anything on the main window. Which is still resizable, so it is not quite as "aggressive" as under Windows, but still prevents keyboard shortcuts to go to the main window.
thanks for providing the test case. I was able to reproduce the issue and I have to confirm it's annoying. I was not aware of the possibility to integrate so much Ruby code into the application's vital events, so I was not testing the interacting with the Macro IDE this far.
The good news is: in my 0.24 beta the macro IDE no longer (or much less) interferes with the code so that issue seems to be fixed already. Because of Python integration the macro IDE was reorganized heavily and apparently one side effect of that was that this issue is fixed. You'll find the current snapshot here http://www.klayout.de/build.html.
But because of the Python integration I completely overhauled the macro integration. One consequence is that the code does not work exactly the same way in 0.24, because the QFlags::DockWidgetArea now is mapped to it's own type. There is no implicit conversion of int to the flags object so the corresponding line is:
Maybe I can provide the implicit conversion, but given the enhancement of the IDE I think it's high time to finish 0.24. I just wish I got more time on that ...
Thank you so much for mentioning version 0.24, even though I couldn't build the current snapshot, I am using the 0.24-python-eval version now and you are correct, the Macro Development window is now much less "aggressive" in grabbing the focus... in fact, I can just leave it open while working on/debugging the code using QDockWidget.
Being still more of a Python than a Ruby programmer, I also appreciate that KLayout supports that language, this is great... at some point I guess I'll have to decide which one to use as the "main" KLayout scripting language though.
I also think that the new Qt constants notation is cleaner now, definitely better in terms of readability than using Fixnum/int numbers found somewhere in the Qt documentation.
Anyway, this solves the focus issue for me and I am looking forward to the official 0.24!
See my comments about the build in the other post. I don't know the reason for the build fail but we should be able to solve that.
Regarding the choice of the language: there is a constant fight between Ruby and Python factions. Python has a lean but somewhat boring syntax while Ruby is richer but less easy to learn. My personal favourite is Ruby too, but that viewpoint is not shared by everybody.
However, under the hood, both languages are more similar that one should expect, so it does not matter much which language you choose. I guess that with the 0.24's Python support, KLayout will be unique in a way that it does not force anybody to use a specific language. It's even possible to use scripts from both worlds within the same tool. You can code PCell's in Python and instantiate them in Ruby for example or you can install scripts written in Python together with some written in Ruby.
Maybe that will help a little to restore peace in the OO scripting world ...