I'm trying to convert the GTK+2 code to compile and run on GTK+3. In the old code I have following:
gtk_widget_push_composite_child()/gtk_widget_pop_composite_child()
Now GTK+3 states that instead I should first call gtk_widget_init_template() and then gtk_widget_class_set_template()/gtk_widget_class_set_template_from_resource().
Now, those 2 functions use an XML template to build the composite widget from. Unfortunately there is no example on how to make one and what to pass to those function(s).
Do I pass the XML file name? The XML tree root node? The schema verification? Trying to google for the code example didn't yield anything useful.
Can anyone shed some light on this please?
There is an old blog post "Announcing Composite Widget Templates" that explains how it works. Usually taking a look at gtk3-demo should shed some light (better to run it).
To pass the name, you call it in the init method, as the example in the blog post:
static void
my_widget_class_init (MyWidgetClass *klass)
{
GtkWidgetClass *widget_class = GTK_WIDGET_CLASS (klass);
/* Setup the template GtkBuilder xml for this class
*/
gtk_widget_class_set_template_from_resource (widget_class, "/org/foo/my/mywidget.ui");
}
static void
my_widget_init (MyWidget *widget)
{
/* Initialize the template for this instance */
gtk_widget_init_template (GTK_WIDGET (widget));
}
The resources' files would look something like:
<gresources>
<gresource prefix="/org/foo/my">
<file alias="ui/password-view.ui" compressed="true" preprocess="xml-stripblanks">myapp-mywidget.ui</file>
</gresource>
</gresources>
In some part of your code, you will need to load the resources' file, where myapp-mywidget.ui is the actual filename with the UI file. You can have one file per template, and all of them listed in the resources' file.
Related
In PhpStorm (and other JetBrains IDE), is it possible to make function attributes as file / resource path?
E.g. in this function:
function mix($file): string
{
// check mix maninfest for $file and return path from mix manifest
return $fire_path_with_cachebuster;
}
I'd like PHP to suggest files in the project as I define $file attribute when calling mix function.
Only manually for the moment, when calling that function 😒. And it's a temp injection (for a session) so it's not convenient:
mix('')
Place caret inside the string parameter
Use Alt + Enter (or via light bulb icon) to bring the Quick Fix / Intentions menu (on some Keymaps it might be different one)
Use "Inject language or reference" option
Then choose "File Reference" entry there (just start typing to filter the list).
The result:
Hopefully they will implement the following tickets for a permanent solution:
Using #[Language] PHP attribute at the function declaration: https://youtrack.jetbrains.com/issue/WI-56996
Or in-place via PHPDoc-like comment (before the parameter when calling that function): https://youtrack.jetbrains.com/issue/WI-20028
Watch those tickets (star/vote/comment) to get notified on any progress (and hopefully speed it up by bringing dev's attention).
Like LazyOne stated, there is currently no way to declare a parameter as being a file reference.
However, you can get a more permanent File Reference "injection" by [mis]using __DIR__.
PhpStorm considers a string mixed with the __DIR__ constant to be a file path:
It isn't perfect as it depends on what directory you are currently located in. If you only want the filename passed to your method, you can wrap the string in basename, or handle that from within your method.
echo mix(basename(__DIR__ . '/slack_bot.php'));
In ASP.NET Core, the JsonConfigurationProvider will load configuration from appsettings.json, and then will read in the environment version, appsettings.{Environment}.json, based on what IHostingEnvironment.EnvironmentName is. The environment version can override the values of the base appsettings.json.
Is there any reasonable way to preview what the resulting overridden configuration looks like?
Obviously, you could write unit tests that explicitly test that elements are overridden to your expectations, but that would be a very laborious workaround with upkeep for every time you change a setting. It's not a good solution if you just wanted to validate that you didn't misplace a bracket or misspell an element name.
Back in ASP.NET's web.config transforms, you could simply right-click on a transform in Visual Studio and choose "Preview Transform". There are also many other ways to preview an XSLT transform outside of Visual Studio. Even for web.config parameterization with Parameters.xml, you could at least execute Web Deploy and review the resulting web.config to make sure it came out right.
There does not seem to be any built-in way to preview appsettings.{Environment}.json's effects on the base file in Visual Studio. I haven't been able to find anything outside of VS to help with this either. JSON overriding doesn't appear to be all that commonplace, even though it is now an integral part of ASP.NET Core.
I've figured out you can achieve a preview with Json.NET's Merge function after loading the appsettings files into JObjects.
Here's a simple console app demonstrating this. Provide it the path to where your appsettings files are and it will emit previews of how they'll look in each environment.
static void Main(string[] args)
{
string targetPath = #"C:\path\to\my\app";
// Parse appsettings.json
var baseConfig = ParseAppSettings($#"{targetPath}\appsettings.json");
// Find all appsettings.{env}.json's
var regex = new Regex(#"appsettings\..+\.json");
var environmentConfigs = Directory.GetFiles(targetPath, "*.json")
.Where(path => regex.IsMatch(path));
foreach (var env in environmentConfigs)
{
// Parse appsettings.{env}.json
var transform = ParseAppSettings(env);
// Clone baseConfig since Merge is a void operation
var result = (JObject)baseConfig.DeepClone();
// Merge the two, making sure to overwrite arrays
result.Merge(transform, new JsonMergeSettings
{
MergeArrayHandling = MergeArrayHandling.Replace
});
// Write the preview to file
string dest = $#"{targetPath}\preview-{Path.GetFileName(env)}";
File.WriteAllText(dest, result.ToString());
}
}
private static JObject ParseAppSettings(string path)
=> JObject.Load(new JsonTextReader(new StreamReader(path)));
While this is no guarantee there won't be some other config source won't override these once deployed, this will at least let you validate that the interactions between these two files will be handled correctly.
There's not really a way to do that, but I think a bit about how this actually works would help you understand why.
With config transforms, there was literal file modification, so it's easy enough to "preview" that, showing the resulting file. The config system in ASP.NET Core is completely different.
It's basically just a dictionary. During startup, each registered configuration provider is run in the order it was registered. The provider reads its configuration source, whether that be a JSON file, system environment variables, command line arguments, etc. and builds key-value pairs, which are then added to the main configuration "dictionary". An "override", such as appsettings.{environment}.json, is really just another JSON provider registered after the appsettings.json provider, which obviously uses a different source (JSON file). Since it's registered after, when an existing key is encountered, its value is overwritten, as is typical for anything being added to a dictionary.
In other words, the "preview" would be completed configuration object (dictionary), which is composed of a number of different sources, not just these JSON files, and things like environment variables or command line arguments will override even the environment-specific JSON (since they're registered after that), so you still wouldn't technically know the the environment-specific JSON applied or not, because the value could be coming from another source that overrode that.
You can use the GetDebugView extension method on the IConfigurationRoot with something like
app.UseEndpoints(endpoints =>
{
if(env.IsDevelopment())
{
endpoints.MapGet("/config", ctx =>
{
var config = (Configuration as IConfigurationRoot).GetDebugView();
return ctx.Response.WriteAsync(config);
});
}
});
However, doing this can impose security risks, as it'll expose all your configuration like connection strings so you should enable this only in development.
You can refer to this article by Andrew Lock to understand how it works: https://andrewlock.net/debugging-configuration-values-in-aspnetcore/
I am using the free edition of SoapUI (version 4.6.1) with multiple workspaces. One of my frustrations is that SoapUI does not seem to support workspace-level custom properties.
The *-soapui-workspace.xml files I have reviewed contain an empty con:settings element (i.e. <con:settings/>). Same in the *-soapui-project.xml files I have reviewed.
My intuition & hope is that these elements allow workspace- or project-level additions to or overrides of settings I see in my general soapui-settings.xml file - e.g. additional global properties that I want when a given workspace is loaded.
However, when I create a settings file SomeService Tests-soapui-settings.xml that contains...
<?xml version="1.0" encoding="UTF-8"?>
<con:soapui-settings xmlns:con="http://eviware.com/soapui/config">
<con:setting id="GlobalPropertySettings#properties"><![CDATA[<xml-fragment xmlns:con="http://eviware.com/soapui/config">
<con:property>
<con:name>WorkspaceCustomPropertyTest</con:name>
<con:value>some value</con:value>
</con:property>
</xml-fragment>]]>
</con:setting>
</con:soapui-settings>
...and set the con:settings element in the SomeService Tests-soapui-workspace.xml file like so...
<?xml version="1.0" encoding="UTF-8"?>
<con:soapui-workspace name="SomeService Tests" soapui-version="4.6.1" projectRoot="${workspaceDir}" xmlns:con="http://eviware.com/soapui/config">
<con:description>Workspace to organize all SomeService test projects.</con:description>
<con:settings>SomeService Tests-soapui-settings.xml</con:settings> <!-- Reference the workspace settings file. -->
<con:project name="SomeService Authentication Tests">SomeService Authentication Tests-soapui-project.xml</con:project>
</con:soapui-workspace>
..., nothing happens.
I do not get an error upon loading the workspace, but I also do not get any indication that the con:settings element is doing anything either. For example, SoapUI Preferences > Global Properties does not list a WorkspaceCustomPropertyTest property.
I can keep tinkering of course, but an explanation of the workspace- and project-file con:settings elements would help.
Searching SO, the SmartBear SoapUI forum, and more broadly for an explanation of the workspace- and project-file con:settings elements has yielded nothing so far.
Can anyone explain how to use the workspace- and project-file con:settings elements?
Alternatively, can anyone shed light on how to achieve a similar result (i.e. workspace-level custom properties) with the free edition of SoapUI?
What about that?
Create a ini("myconfig.groovy") file("assuming that this file will be in the same directory of your project file"):
global_property='Global value'
Use this groovy script to grab the property:
// Script imports
import com.eviware.soapui.support.GroovyUtils
import groovy.util.ConfigSlurper
// Grovvy utils handle OS directories path abstraction
def groovyUtils = new GroovyUtils(context)
def config = new ConfigSlurper().parse(new File(groovyUtils.projectPath + '/myconfig.groovy').toURL())
// Just logging the property but you can set the property here
log.info config.global_property
Then you can add the value to the desired object at run time.
It doesn't seem possible to do it at the workspace level. You could do it at one of the testing levels, see: http://www.soapui.org/Functional-Testing/working-with-properties.html
SoapUI does support global properties.
In File> Preferences> Global Properties
Here you can assign Global Properties that spans all projects. Sadly, currently, it will be used for all work spaces. Hope this helps, having a groovy script to manually handle everything just seems a bit over kill to me.
I have a project in Apps script that uses several libraries. The project needed a more complex logger (logging levels, color coding) so I wrote one that outputs to google docs. All is fine and dandy if I immediately print the output to the google doc, when I import the logger in all of the libraries separately. However I noticed that when doing a lot of logging it takes much longer than without. So I am looking for a way to write all of the output in a single go at the end when the main script finishes.
This would require either:
Being able to define the logging library once (in the main file) and somehow accessing this in the attached libs. I can't seem to find a way to get the main projects closure from within the libraries though.
Some sort of singleton logger object. Not sure if this is possible from with a library, I have trouble figuring it out either way.
Extending the built-in Logger to suit my needs, not sure though...
My project looks at follows:
Main Project
Library 1
Library 2
Library 3
Library 4
This is how I use my current logger:
var logger = new BetterLogger(/* logging level */);
logger.warn('this is a warning');
Thanks!
Instead of writing to the file at each logged message (which is the source of your slow down), you could write your log messages to the Logger Library's ScriptDB instance and add a .write() method to your logger that will output the messages in one go. Your logger constructor can take a messageGroup parameter which can serve as a unique identifier for the lines you would like to write. This would also allow you to use different files for logging output.
As you build your messages into proper output to write to the file (don't write each line individually, batch operations are your friend), you might want to remove the message from the ScriptDB. However, it might also be a nice place to pull back old logs.
Your message object might look something like this:
{
message: "My message",
color: "red",
messageGroup: "groupName",
level: 25,
timeStamp: new Date().getTime(), //ScriptDB won't take date objects natively
loggingFile: "Document Key"
}
The query would look like:
var db = ScriptDb.getMyDb();
var results = db.query({messageGroup: "groupName"}).sortBy("timeStamp",db.NUMERIC);
I use Doxygen for documenting the JavaScript API of my C++ (Qt) project. The idea is to write one specific documentation for the JavaScript interfaces, and one for the C++ classes us usual.
One example (datasource.dox) looks like this:
\addtogroup JavaScriptAPI
#{
...
\class DataSource
\brief DataSource is the .... some doc goes here ....
\section formats Supported formats
....
\fn isOpen()
\brief returns true if the data source is currently open...
...
#}
The generated help looks nice w.r.t. the class description (or 'object'-description), but the function documentation (isOpen(), ...) is missing. Doxygen creates warning messages like:
Warning: documented function `bool isOpen' was not declared or defined.
The question, now: can I somehow force doxygen to use my \fn-d function descriptions? It would be nice, if doxygen created all those member indices for me...
Two approaches for using doxygen with Javascript are listed here http://www.doxygen.org/helpers.html
(look for JavaScript)