In GIMP the spinboxes they use for brush sizes allow for
manual typing
up-down spinning
They also provide a bar that can be dragged which provides a nice indication of the range that spinbox can take.
Is this possible with pygtk?
You probably want to use Gtk.SpimButton and Gtk.Scale:
https://developer.gnome.org/gtk3/stable/GtkSpinButton.html
https://developer.gnome.org/gtk3/stable/GtkScale.html
These are the GTK+3 version but you can also find them in GTK+2 but I strongly suggest not to use PyGTK2 since it's not maintained anymore, use the introspection bindings instead through PyGobject:
https://wiki.gnome.org/action/show/Projects/PyGObject
You also have a tutorial:
https://python-gtk-3-tutorial.readthedocs.org/en/latest/index.html
and the API reference:
http://lazka.github.io/pgi-docs/
http://lazka.github.io/pgi-docs/api/Gtk_3.0/classes/SpinButton.html
http://lazka.github.io/pgi-docs/api/Gtk_3.0/classes/Scale.html
Related
In vscode, the new Sticky scroll doesn't seem to work out of the box with my custom language extension. Is there some interface my language needs to implement in order to support it?
The new Sticky Scroll feature seems to be based on the language elements (class/interface/namespace/function/method/constructor) being recognized, and available in the Outline view. This means your custom language must have a Language Server or any other tooling that provides such elements to the editor.
If your language does provide that, but is not being properly supported in the new Sticky Scroll feature, I suggest you to open an issue in VS Code repo. As you can see (https://github.com/microsoft/vscode/labels/editor-sticky-scroll), there are a few issues reported.
Hope this helps
That could change with VSCode 1.72 and issue 157165 "Add option to base Sticky Scroll on indent, not Document Symbols"
Basing Sticky Scroll on class/function/namespace etc. makes a lot of sense, but only as long as there is an active language server or language extension that provides good Document Symbols (Outline).
For all languages that either have no LSP (so, so many), whose LSP provides no Outline, whose LSP provide invalid Outline or which simply have no concept of functions/classes etc., Sticky Scroll can not be leveraged :-(
I'd argue that in many cases the respective context could be inferred from the indentation instead.
I realize this may not be desirable by default, so perhaps it should be either hidden behind a flag or configurable per language. For example, in a large JSON file, you might then get this context:
1 {
51 "a": {
52 "b": [
-----------------------------------------------
74 "current_line",
75 "..."
Personally, I'd like to have SS in CoffeeScript, Crystal, AutoHotkey, Markdown, JSON, and pretty much everywhere else except maybe plain text files.
This implemented with PR 159198;
When no document symbol provider use the folding model for the sticky scroll:
This is available in VSCode insiders today.
I would like to style notifications in Vaadin Flow (19+), in Java, exactly as shown here in typescript, by assigning a theme and not setting the color of the elements (as shown in the java example). Apart the fact that setting the color is troublesome (foreground, background...) and fragile (e.g. switching to dark mode), the Java example shows setting a CSS color, I would expect to be allowed to use Lumo color variables (e.g. --lumo-success-color). Is this possible? Can anybody show an example?
You can use the addThemeVariants() method to define the variant you want to use:
Notification notification = new Notification();
notification.addThemeVariants(NotificationVariant.LUMO_PRIMARY);
The Java examples have not been moved over to the new docs site yet, you can find them here https://vaadin.com/components/vaadin-notification/java-examples/theme-variants
I'm new to PyopenGL and i'm currently working on a code originally based on the pyggel library, but now I'd like to add some features from GLUT (menu & text) and I'm not really sure how I should join both (if possible).
In GLUT, running glutMainLoop() is required, but on the other hand I have this run() routine:
def run(self):
while 1:
self.clock.tick(60)
self.getInput()
self.processInput()
pyggel.view.clear_screen()
self.mouse_over_object = self.scene.render(self.camera)
pyggel.view.refresh_screen()
#glutMainLoop()
Putting the GLUT routine inside my run() doesn't work (it crashes when it gets to the glutMainLoop).
So, how can I join both loops? Can I? I'm guessing that's what I need to make both things work.
Thanks in advance!
You likely are not going to find this easy to do. Pyggel is based on the Pygame GUI framework, while GLUT is its own GUI framework. You may be able to get text-rendering working, as under the covers GLUT is just doing regular OpenGL for that, but the menus are not going to easily work under Pyggel.
Pyggel has both text-rendering and a GUI framework that includes menus, frames, buttons, labels, etc. You likely want to use that if you're using Pyggel in your project there is an example of GUI usage here:
http://code.google.com/p/pyggel/source/browse/trunk/examples_and_tutorials/tut8-gui.py
I'm building a QuickLook plugin. I want to change the width of the windows that pops up when user hits the spacebar.
I've read there are two keys in the info.plist file of the project where height and width are customisable. Even if I change those values I can't get the size of the preview windows to my desired one.
I don't know what else to try. Any idea?
Thanks!
Thought I'd dig a little on this. I have not tried any of the following suggestions, so nobody get their hopes up. I'll assume you're using the generator callback:
OSStatus (*GeneratePreviewForURL)(
void *thisInterface,
QLPreviewRequestRef preview,
CFURLRef url,
CFStringRef contentTypeUTI,
CFDictionaryRef options
);
Before anything else, you might manually check the options dictionary argument and verify that the kQLPreviewPropertyWidthKey and kQLPreviewPropertyHeightKey keys are indeed mapped to the desired CFNumber values.
Referring to each of these properties, the Apple QuickLook programming guide says:
Note that this property is a hint; Quick Look might set the width
automatically for some types of previews. The value must be
encapsulated in a CFNumber object.
(Edit: If your preview representation is flexible, you might try finding a preview type for which QuickLook honors your size hints, as per the statement above. Just a thought.)
Running nm on the QuickLook framework binary revealed some undocumented kQLPreviewProperty-- constants as well as the aforementioned width and height keys. One that caught my attention was kQLPreviewPropertyAutoSizeKey. Recalling Apple's statement about ignoring the hints to set the size automatically, this might be significant? Following the convention in QuickLook.framework/Headers/QLBase.h, you might try declaring
extern const CFStringRef kQLPreviewPropertyAutoSizeKey;
Then you could try associating a CFNumber 0 with that property key in the options dictionary. There are other undocumented keys of note, such as kQLPreviewPropertyAttributesKey.
Back to the Info.plist you mentioned, Apple says about those keys QLPreviewWidth and QLPreviewHeight:
This number gives Quick Look a hint for the width (in points) of
previews. It uses these values if the generator takes too long to
produce the preview. (emphasis added)
This is where someone makes the terrible suggestion of calling sleep() in your generator. But I'm perplexed as to why Apple would make following the size hints dependent on the generator latency. (?)
Edit: Also note the above statement says the Info.plist hints must be expressed in points (not pixels), a unit dependent on the user's screen resolution.
Recently I was developing a Quick Look Plugin myself which uses HTML+CSS and faced the same problem.
The solution for my was to test the plugin not within Xcode and qlmanage as the executable but instead to try the real .qlgenerator from my user library.
When invoking the generator from my user library, the Quick Look window was resized exactly the way I specified in the *-Info.plist.
I've run into the same problem, and may offer some clues: In my case I'm generating an image quick look preview for my custom file format. I initiate the preview context to draw my preview into using
CGContextRef QLPreviewRequestCreateContext(QLPreviewRequestRef preview, CGSize size, Boolean isBitmap, CFDictionaryRef properties);
The curious thing is that if I set isBitmap to true, quick look adjusts the preview panel size to the size specified for the context (up to a certain size at least). But if you set isBitmap to false, it seems to disregard the context size and instead always shows a full size preview panel with the vector graphics image scaled to cover the entire panel.
So, if you use a bitmap graphical preview context, it seems the preview panel will be set to the size of the context you specify. However, I haven't found any way to set the size of the panel when using a vector graphic preview context (which is what I want).
I'm looking for a guide or sample code for writing Mac OS X Finder plugins? It would like to know how to do some simple actions:
adding image overlayers to icons
adding context menu items
listen to file changes
I found the following two resources:
Writing Contextual Menu Plugins for OS X: An outdated document from 2002 that uses the COM API targeting Mac OS X 8/9.
SCPlugin: Open-source SVN Mac application that includes a Finder plug-in.
I am tempted to review the SCPlugin code, but was hoping to find an easier sample to digest.
The Finder Icon Overlay example project represents a small and very basic but actually working example of the answer below.
https://github.com/lesnie/Finder-Icon-Overlay
I know this is so old, but some may be still interested in topic (?)
Here is what I have it done under Leopard (10.6). At first proper Finder's headers are needed. Use class-dump tool to get it. Then write your code as a SIMBL plugin (refer to documentation how to do it), swizzling some methods. For instance to draw something over icon in ListView, drawIconWithFrame: method of TIconAndTextCell method must be overriden.
Here's the code for method swizzling:
+ (void) Plugin_load
{
Method old, new;
Class self_class = [self class];
Class finder_class = [objc_getClass("TIconAndTextCell") class];
class_addMethod(finder_class, #selector(FT_drawIconWithFrame:),
class_getMethodImplementation(self_class, #selector(FT_drawIconWithFrame:)),"v#:{CGRect={CGPoint=dd}{CGSize=dd}}");
old = class_getInstanceMethod(finder_class, #selector(drawIconWithFrame:));
new = class_getInstanceMethod(finder_class, #selector(FT_drawIconWithFrame:));
method_exchangeImplementations(old, new);
}
I am overriding "drawIconWithFrame:" method with my method "FT_drawIconWithFrame:". Below is sample implementation for this method.
- (void) FT_drawIconWithFrame:(struct CGRect)arg1
{
[self FT_drawIconWithFrame:arg1];
if ([self respondsToSelector:#selector(node)]) {
if ([[[[NSClassFromString(#"FINode") nodeWithFENode:[(TNodeIconAndNameCell *)self node]] fullPath] lastPathComponent] hasPrefix:#"A"])
[myPrettyIconOverlayImage drawInRect:NSMakeRect(arg1.origin.x, arg1.origin.y, arg1.size.height, arg1.size.height) fromRect:NSZeroRect operation:NSCompositeSourceOver fraction:1.0];
}
}
Essentially it draws "myPrettyIconOverlayImage" over every icon for file with filename starts with letter "A". This logic is up to you.
Pay attention to this line: [self FT_drawIconWithFrame:arg1]; this is how to call 'super' in order to get normal icon and name etc. I know, looks weird, like loop, but actually it isn't. Then wrap in into SIMBL plugin, install SIMBL and ...run.
Due to changes in Lion some work have to be done from scratch (make new "Finder.h" file with all declarations needed in it, find proper classess and methods to override), but this technique still works.
Happy hacking!
For Yosemite (MacOS 10.10 & newer), you can use Apple's FinderSync framework, which allows Finder extensions to:
Express interest in specific folder hierarchies
Provide "badges" to
indicate the status of items inside those hierarchies
Provide dynamic
menu items in Finder contextual menus, when the selected items (or
the window target) are in those hierarchies
Provide a Toolbar Item
that displays a menu with dynamic items (even if the selection is
unrelated)
Sadly, programming a Finder plugin actually does still require getting your hands dirty with COM. If you look at the SCFinderPlugin subproject of the SCPlugin project, you will find that it follows exactly the same techniques outlined in your first link, including setting up a vtable for COM, writing AddRef/ReleaseRef functions, and so on. Writing a plugin, where you're simultaneously managing old-school Carbon memory management, COM-style memory management, and Cocoa/new-style Carbon memory management, can be an incredible pain—and that totally ignores the fact that you'll be interacting in three or more radically different APIs, with different naming conventions and calling semantics. Calling the situation hysterically poor would be a vast understatement.
On the bright side, the Finder in Mac OS X 10.6 Snow Leopard has been fully rewritten in Cocoa--and with that come vastly superior plugin interfaces. If you are lucky enough to be in a situation where you can actually only target Snow Leopard, you probably should grab an ADC Premier or higher membership, download the prerelease builds, and code against that. Besides, your plugin may not work on 10.6 anyway without a Cocoa rewrite, so it might make good sense to take a look at Snow Leopard before it gets released, regardless.
There is no official or supported plugin system for the Finder. Starting with OS X 10.6, you will need to inject code into the Finder process and override objective C methods in the Finder process.
I've done this for a proprietary project. I can tell you that the reason that there are no examples or tutorials for this is because it is a significantly difficult and time consuming development task. For this reason, there's plenty of incentive for individuals or organizations who have accomplished this to guard the specifics of their process closely.
If there's any way at all that you can accomplish your goal using the Services API, do it. Writing a Finder plugin will take you 1-2 solid months of painstaking development and reasonably deep knowledge of C and Objective-C internals.
If you're still convinced that you want do to this, grab mach_star. Good luck.
As far as I know, there's no official plugin architecture for the Finder. You may be able to add image overlays to icons through an external application without having to hook into the Finder, although it wouldn't be on the fly. I don't think there is a way to add contextual menu items aside from Folder Actions and Automator. You can also look into writing an external application to monitor File System changes using the FSEvents API.
Here's a completed solution for Finder icon badges and contextual menus in Lion and Mountain Lion using the techniques described by Les Nie.
Liferay Nativity provides a scripting bundle that will swizzle the relevant Finder methods and a Java client for setting the icons and context menus. It also includes equivalent projects for Windows and Linux.
The project is open source under LGPL, so feel free to contribute any bug fixes or improvements!
The pickings are slim; it's never been really clear to me whether Finder Plugins are actually supported. A few more leads, though:
SampleCMPlugIn - Carbon-based of course, since so is Finder. Note that almost any Finder plugin is probably going to stop working with 10.6.
Automator can save things as a "Finder plugin." It's a more supported version of what you're discussing, but of course less flexible.
To add Finder/File browser icon overlays and context menus, in a cross-platform manner, from Java, take a look at the Liferay Nativity library.
I also make mention of this in another SO post, which also contains links to Apple's 'Finder Sync' docs and API.