Re: [Vala] valadoc Question
On Sat, Mar 24, 2018 at 6:06 AM, Al Thomas via vala-list <vala-list@gnome.org> wrote: > On Friday, 23 March 2018, 19:00:09 GMT, Steven Oliver <oliver.ste...@gmail.com> wrote: How do I determine the list of icon names I can pick from? For whatever reason valadoc doesn't list them. Is there somewhere else I can look for the list? I think what you want is the Freedesktop.org icon naming specification:https://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html This may help a little too:https://stackoverflow.com/questions/36805505/gtk-stock-is-deprecated-whats-the-alternative/ Regards, The gtk3-icon-browser program is useful here too - it shows what icon is will be used for each, and lets you search icon names as well. //Mike -- ⊨ Michael Gratton, Percept Wrangler. ⚙ <http://mjog.vee.net/> ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] GLib.assert_no_error not working?
On Fri, Mar 9, 2018 at 10:57 PM, Al Thomas <astav...@yahoo.co.uk> wrote: Of course! I hope I understand now. assert_no_error is used to check the error is unset. The assertion is from GLib and used with C. So in C you have GError as an out argument and if the argument is null then assert_no_error passes. That is the point of the argument. Huh, I see what you mean now. But again, why does GLib bother with the out argument? If it's not null the assert will trip and the program will exit, if not value of the out param will always be null. Pretty weird. In Vala, however, the GError is hidden. It is only exposed inside the catch block and so will always be set. So I think I understand now. You know the error will always be set so it will always fail and then print the values of the GError. No no, the idea is that some call may throw an error but it shouldn't. However if it does it is useful to know what the error is, to aid debugging. For some background, Geary is using Julien's TestCase class for unit testing: https://git.gnome.org/browse/geary/tree/test/testcase.vala At the moment, test cases must catch all exceptions manually since the TestMethod delegate defined in that class doesn't allow them to throw errors. This is pretty annoying to have to do manually for every method that may throw an error, so I am modifying TestMethod to permit throwing errors and are catching them in the test harness instead. Thus it is useful if the test harness pints out the details of the unexpected error, so we know what the unexpected error was. Hence I was interested in assert_no_error() for it's printing of the error details, not for it asserting that the error was null. Thinking it through again, it looks like assert_no_error is broken in GLib. I think assert_false is as well. Have you ever tried assert_false( false )? That should pass, but fails for me. I haven't tried assert_false, because I ended up rolling my own version of all of the GLib assert_* methods. I've basically given up on GLib's test methods because they seem pretty useless to call from vala, and don't let you provide a human readable string as additional context. //Mike -- ⊨ Michael Gratton, Percept Wrangler. ⚙ <http://mjog.vee.net/> ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Using databases with Vala
On Fri, Mar 9, 2018 at 1:03 PM, Steven Oliver <"oliver.steven"@gmail.com> wrote: The only one I'm aware of is Geary, but ripping the database layer out of Geary would be quite the task and probably more than I would need. Geary's low-level DB layer isn't too tightly coupled to the app. You might be just able to pull out the classes under src/engine/db, replace the use of Geary.BaseObject with GLib.Object for any classes that use it and be good to go. I'd definitely be open to breaking it out as a separate library if it means more people contributing to it. In particular, it would be great to add a high-level query interface like JPA/Hibernate criteria queries so we can stop doing SQL munging in the app. //Mike -- ⊨ Michael Gratton, Percept Wrangler. ⚙ <http://mjog.vee.net/> ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] GLib.assert_no_error not working?
On Thu, Mar 8, 2018 at 9:26 PM, Al Thomas <astav...@yahoo.co.uk> wrote: The assertion is in a catch block so err will be set. Whereas assert_no_error is used to check err is unset (i.e. null). The line about 'produce a message that includes the error message and code' seems like a copy/paste error in the documentation. That doesn't seem right at all. What's the point of the argument then? What you might want is assert_error, but the C docs for that advise 'If you want to test that err is set, but don't care what it's set to, just use g_assert (err != NULL)' I'd like to stop the test if an exception has been thrown, i.e. it's abnormal that an error has been thrown. So assert_error is not the right check since it's the opposite of what I am looking for. "assert(err == NULL)" would be correct, but that it wouldn't tell me what the unexpected error was. //Mike -- ⊨ Michael Gratton, Percept Wrangler. ⚙ <http://mjog.vee.net/> ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
[Vala] GLib.assert_no_error not working?
Hey all,
GLib.assert_no_error doesn't seem to do anything that its API docs
advertises for me - doesn't asset, doesn't pretty print the error
message.
See the attached minimal test case, per the comments I'd expect it to
abort on line 9, but it actually aborts on line 11. This is what I get:
mjg@payens:~$ valac --pkg glib-2.0 -g assert_no_error.vala
mjg@payens:~$ ./assert_no_error
/chucker: **
ERROR:/home/mjg/assert_no_error.vala:11:__lambda4_: assertion failed:
(false)
Aborted (core dumped)
Am I missing something here?
Cheers,
//Mike
--
⊨ Michael Gratton, Percept Wrangler.
⚙ <http://mjog.vee.net/>
public static int main (string[] args) {
Test.init (ref args);
Test.add_func ("/chucker", () => {
try {
throw new FileError.FAILED("This should get printed");
} catch (Error err) {
// Should print code then abort
assert_no_error(err);
// Actually aborts here
assert(false);
}
});
Test.run ();
return 0;
}
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list
[Vala] Structured logging and source files/lines/functions
Hi all, I'm investigating using structured logging[0] for Geary, and it recommends including source file, line number and function call names in the logged data for latter debugging. In C, these are set by G_DEBUG_HERE(), g_message, and so on, and calling those from Vala seems to include this info as advertised, I can't work out how to find this information in Vala for direct or wrapped calls to GLib.log_structured. Is it available at all? Looking a the compiler source, it doesn't seem to be getting set as a define at compile time, and I couldn't find G_STRLOC and G_STRFUNC on valadoc.org, but there aren't any tickets open in b.g.o for it, so I'm wondering if this is possible at the moment via some other means? Also, the docs for structured logging highly recommends defining G_LOG_USE_STRUCTURED before including glib.h. Is there any way to do that in the source, or do I need to use a compiler define to be able to? Cheers! //Mike [0] - <https://valadoc.org/glib-2.0/GLib.log_structured.html> -- ⊨ Michael Gratton, Percept Wrangler. ⚙ <http://mjog.vee.net/> ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] glib backtrace
Hey Mickey, On Wed, Nov 22, 2017 at 10:52 PM, Dr. Michael Lauer <mic...@vanille.de> wrote: I have (and I’m responsible for their bindings in linux.vapi). FSO has stalled for a couple of years, so I don’t know whether this still compiles, but check https://github.com/freesmartphone/cornucopia/blob/master/libfsoframework/fsobasics/utilities.vala for an example using the backtrace functionality. Thanks for the link. I guess based on the VAPI name it's Linux specific - but does it rely on glibc or is it actually using something Linux-kernel-specific? Cheers, //Mike -- ⊨ Michael Gratton, Percept Wrangler. ⚙ <http://mjog.vee.net/> ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Introspection for exception instances
Hey Al,
On Tue, Nov 14, 2017 at 3:09 AM, Al Thomas <astav...@yahoo.co.uk> wrote:
I hope this gets you a step further, but I've not applied this with
GLib's cancellable.
The general pattern is:
void main () {
try {
test ();
} catch (IOError error) {
print (error.message + "\n");
}
}
void test () throws IOError {
throw new IOError.CANCELLED ("This test has been cancelled");
}
Just compile with valac --pkg gio-2.0 cancellable_error.vala and you
will see
the message.
Yeah, that will get me the message which is great, but I'm interested
in the developer-readable string version of the domain and code.
So for example being able to call `error.to_string()` and get
"IOError.CANCELLED: This test has been cancelled" returned would be
good, but it would be even better to be able to get the individual
components, e.g. "IOError" and "CANCELLED".
I assumed CANCELLABLE was a typo.
Yeah sure was, sorry. I need a type-checker for my email composer.
//Mike
--
⊨ Michael Gratton, Percept Wrangler.
⚙ <http://mjog.vee.net/>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Introspection for exception instances
PS: Has anyone used the glib backgrace_symbols() function[0] to generate a stack trace in Vala? [0] - <https://www.gnu.org/software/libc/manual/html_node/Backtraces.html> -- ⊨ Michael Gratton, Percept Wrangler. ⚙ <http://mjog.vee.net/> ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
[Vala] Introspection for exception instances
Hey all,
I'm looking into improving Geary's error reporting at the moment, and
would like to be able to reconstruct the domain and code names that
were given in the source file for an arbitrary error when catching it,
so that users can copy & paste some "technical details" and report it
in a bug, if they are so inclined. For example, given an instance of a
IOError.CANCELLABLE, I'd like to be able to come up with a string
representation of it as "IOError.CANCELLABLE". At the moment the best I
can get is the quark and code as strings, i.e. "g-io-error" and "32"
(or whatever).
I understand that Vala Error objects are convenience representations of
the underlying GError and not full classes, however since under the
hood a Vala errordomain generates an enum in C, I'd hope that I should
at least be able to convert the code from an int in an arbitrary error
domain back to a string, but can't work out a way to do it. Is this
possible? A nicer version of the domain value instead of the quark
string value would be great as well.
Relatedly, since the error's code is an enum, it would be handy to be
able to use it in a switch statement, e.g.:
switch (io_error.code) {
case IOError.CANCELLABLE:
...
break;
}
But again unless I am missing something, this doesn't seem to be
currently supported?
//Mike
--
⊨ Michael Gratton, Percept Wrangler.
⚙ <http://mjog.vee.net/>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list
[Vala] notify for synthetic properties?
Hey people,
Say you have a GObject with a synthetic property, the value of which
depends on some other value, e.g.:
public string value {
get { return entry.get_text(); }
set { entry.set_text(value); }
}
private Gtk.Entry entry;
You want to want to get notifies when the synthetic property changes,
which is obviously dependent on the value being used.
So you can manually add handlers for the dependent value and call
notify_property("value") when it changes, or you can use GObject
bindings. But both of these suck since they add code cruft that is off
somewhere far away from the declarations, and that makes it hard to
maintain and understand what is going with the values.
Is there a nicer way to do this in vala?
//Mike
--
⊨ Michael Gratton, Percept Wrangler.
⚙ <http://mjog.vee.net/>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Roadmap for extending Vala's reach
Hey Guillaume,
I think this is a generally good idea - didn't vala already have some
notion of profiles already though?
In particular I like getting rid of the implicit "using GLib" - explcit
is always better. It's especially annoying given every single symbol
from all of of GLib, GObject and GIO is crammed into that one namespace.
WRT --nostdpkg, I kind of wonder if it's a better idea to instead
simply bump the major version number and drop backwards compat, so we
know that existing projects will continue to compile fine with the old
0.x series, at no additional development overhead cost. Once projects
have migrated to having an explicit --pkg=glib-2.0 and "using GLib"
then they can just cut over to 1.x of the compiler.
This would also be a good opportunity to split GLib, GObject and GIO up
into separate namespaces, which would be more consistent with this
suggested approach of using --pkg to enable compiler-specific features.
//Mike
--
⊨ Michael Gratton, Percept Wrangler.
⚙ <http://mjog.vee.net/>
On Sun, May 7, 2017 at 5:26 AM, Guillaume Poirier-Morency
<guillaumepoiriermore...@gmail.com> wrote:
Hello all!
We currently have a very promiscous relationship with GLib and I would
like to propose some changes to make this more explicit.
Each --pkg argument would consist of a VAPI and a compiler plugin
(from
wip/transform) for generating specific code and extending the language
syntax. One optional plugin per package seems sane to me.
No --pkg arguments at all:
* basic Vala syntax
* basic C codegen
* standard C types (int, uint -> unsigned int, char, uchar, ...)
* no API
At this point, one could introduce a different set of definitions for
supporting, let's say, a micro-controller C standard library in just a
matter of a --pkg flag.
With --pkg=posix
* posix C API
With --pkg=glib-2.0
* shadowed standard C types in GLib.* namespace, which would become
in
default with a 'using GLib;' declaration
* GLib C API
* support for basic introspection (--gir and the like)
No more imlicit 'using GLib;'. However, including it would shadow all
the numerical types and produce a nice GLib-friendly API.
With --pkg=gobject-2.0
* GObject API
* typeof
* signals
* support for advanced introspection
With --pkg=gio-2.0
* GIO API
* asynchronous primitives
* DBus code generator
With --pkg=gtk-3.0
* GTK API
* [GtkBuilder] annotations
We can have a pure Posix C backend and compile anything with:
valac --ccode --pkg=posix main.vala
public int main () {} => int main (void) {}
Or if one would like to target Emscripten platform:
valac --ccode --pkg=emscripten main.vala
public int main () {} => #include int main (void) {}
For usual GLib code:
valac --ccode --pkg=glib-2.0 main.vala
using GLib;
public int main () {} => gint main (void) {}
It would be breaking stuff that is not explicitly using --pkg=glib-2.0
and 'using GLib'. We could actually use the '--nostdpkg' switch to
sort
of reset the compiler down to it's most basic feature set and wait
until 1.0 to drop it and have some good defaults.
At first, it would be to make --nostdpkg work flawlessly while
preserving entire backward-compatibility. That'll be good for a minor
release.
Tell me what you think about this!
--
Guillaume Poirier-Morency <guillaumepoiriermore...@gmail.com>
Étudiant au baccalauréat en informatique à l'Université de
Montréal
Stagiaire de recherche à l'IRIC
Mon blog: https://arteymix.github.io/
Clé PGP: B1AD6EA5
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Nice stuff incoming for the next Meson release
Hi Guillaume, Thanks for this! We're thinking testing the waters with Meson for Geary[0], this might make it a bit easer to port to from cmake. //Mike [0] - <https://bugzilla.gnome.org/show_bug.cgi?id=777044> -- ⊨ Michael Gratton, Percept Wrangler. ⚙ <http://mjog.vee.net/> On Wed, Apr 12, 2017 at 3:02 AM, Guillaume Poirier-Morency <guillaumepoiriermore...@gmail.com> wrote: There's a couple of changes on the way for the next release of Meson (0.40.0) that will have a really good and positive aspect for people using Vala: - support for multiple install directories (girdir, vapidir, includedir, ...) - support for VALAFLAGS and -Dvala_args to pass compiler arguments from an external source - arguments for specific GIR and VAPI install directory - better and more consistent arguments for Vala targets If you don't use Meson yet, I strongly suggest you to consider using it and help me making it into tier-1 language! Related PRs: - https://github.com/mesonbuild/meson/pull/1469 - https://github.com/mesonbuild/meson/pull/1599 - https://github.com/mesonbuild/meson/pull/954 - https://github.com/mesonbuild/meson/pull/1603 - https://github.com/mesonbuild/meson/pull/1610 -- Guillaume Poirier-Morency <guillaumepoiriermore...@gmail.com> Étudiant au baccalauréat en Informatique à l'Université de Montréal Chercheur boursier à l'Institut de recherche en immunologie et en cancérologie *Page Web:* arteymix.github.io *Clé PGP:* B1AD6EA5 <https://pgp.mit.edu/pks/lookup?op=vindex=0x1CCFC3A2B1AD6EA5> ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Valadoc.org is fully operational again
On Wed, Nov 23, 2016 at 9:56 PM, Al Thomas via vala-list <vala-list@gnome.org> wrote: In case anyone hadn't noticed valadoc.org is fully working again. Oh, I hadn't — thanks for the head-up. This is excellent news! Thanks to Elementary OS [1] who are hosting the site [2]. [snip] Thanks should also go out to Chris Daley of Valadate project for hosting a mirror ( http://valadoc.valadate.org ) and the company RooJSolutions ( http://valadoc.roojs.com ) for also hosting a mirror while things got back to normal. Seconded, and to everyone else working on it. Cheers, people! //Mike -- ⊨ Michael Gratton, Percept Wrangler. ⚙ <http://mjog.vee.net/> ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] [Announcement] Vala will use GTask for async code instead of GSimpleAsyncResult if --target-glib=2.36 or greater is selected
Hi all, I just wanted to quickly say thanks to everyone involved with this. It will cut down the amount of warnings generated when compiling Geary by a huge amount! //Mike -- ⊨ Michael Gratton, Percept Wrangler. ⚙ <http://mjog.vee.net/> On Mon, Nov 21, 2016 at 10:27 PM, Al Thomas <astav...@yahoo.co.uk> wrote: A patch to Vala's master development branch was made this weekend. The patch changes the C code generated from Vala's async code. Future versions of Vala (0.36 and above) will use GLib's GTask instead of GSimpleAsyncResult when --target-glib=2.36 or greater is selected. Vala 0.36 is expected with GNOME 3.24 in March 2017. The patch is: https://git.gnome.org/browse/vala/commit/?id=14ca2e09f9021e681947fa3f1fb5c1a6974059ae Thanks to Carlos Garnacho for the main work on the patch, to Ben Iofel for fixing cancelled tasks and to everyone else who tested and fed back on the patch. To see more details of this example of collaborative working in the Vala community: https://bugzilla.gnome.org/show_bug.cgi?id=763345 If you use async code and want to test your project then download and build Vala from git master. Instructions are available here: https://wiki.gnome.org/Projects/Genie/Developing#Building_valac_from_Source If your testing uncovers a bug then feedback through bugzilla: https://bugzilla.gnome.org/page.cgi?id=browse.html=vala ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] The future of Vala
On Fri, Sep 9, 2016 at 3:34 AM, Timm Bäder <m...@baedert.org> wrote: So... what's the deal here? Is there any way forward one could look into? Is it wip/transform? IIRC there was some dbus stuff broken here? Are there any TODO items for cleaning up the compiler? Should we just tell people to not use Vala in the first place (which would be better for the in the long run)? All of these are fine, but the current situation not so much. I'd like to see Vala continue, it's IMHO the only reasonable way to write high-level apps in GObject, but I /am/ biased. :) As people have pointed out, we can get patches landed, bindings are being updated, and we can respond and triage bugs, improve automated testing coverage and debate hosting choice of infrastructure, but none of that's going to be terribly useful unless significant new releases continue. It really sounds like Vala needs some maintainers. Perhaps Jürg, Luca and Flo are still keen but too busy at the moment, perhaps someone else needs to step up. But either way there needs to be one or a few people with some idea of where they want Vala to go, who have the time to put in to make sure it starts heading in that direction. In the end, its the maintainers that would decide if things like wip/transform is the way to go or not. //Mike -- ⊨ Michael Gratton, Percept Wrangler. ⚙ <http://mjog.vee.net/> ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] The future of Vala
On Tue, Sep 13, 2016 at 2:19 AM, oyster <lepto.pyt...@gmail.com> wrote: some killer apps may be a good AD. Like these? <https://wiki.gnome.org/Projects/Vala/Documentation#Projects_Developed_in_Vala> ;) -- ⊨ Michael Gratton, Percept Wrangler. ⚙ <http://mjog.vee.net/> ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Global key shortcuts
On Sat, Aug 20, 2016 at 4:33 AM, rastersoft <ras...@rastersoft.com> wrote: I'm working on a program that needs to respond to an specific key always, so when I press it, it will show its window. How can I do it from Vala? Is it possible to do that in a way compatible with wayland? (let's say: register a DBus method to be called when that key is pressed, or something like that...) So even when the window is hidden or not focused or whatnot? That's more of a desktop integration issue, isn't it? Maybe there is a FDO/XDG method for registering them. In any case, I imagine you'll probably want to implement GApplication/GtkApplication and have you app raise/focus/etc the window in response to the activate signal. The desktop then just needs to activate the app in response to the global shortcut, by invoking that signal via DBus or by executing a new instance of the app, which would also send the signal to the already running instance. //Mike -- ⊨ Michael Gratton, Percept Wrangler. ⚙ <http://mjog.vee.net/> ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] refcounting, signals and closures
On Thu, Aug 11, 2016 at 12:10 PM, Michael Gratton <m...@vee.net> wrote:
I'm trying to track down a memory leak in Geary. I have a custom
subclass of Gtk.ListBox, instances of which are frequently added and
removed from the UI.
[snip]
The only things I can find that could still be holding a reference
are registered signal handlers, both to instance methods, eg:
> this.row_activated.connect(on_row_activated);
And using closures/lambdas:
> this.size_allocate.connect(() => { check_mark_read(); });
So it turns out that the problem was neither of the above. Rather, it
was due to instance methods being used as higher-order functions by
being passed as arguments to methods.
For example:
public class Example : Gtk.ListBox {
public Example() {
set_sort_func(on_sort);
}
private int on_sort(Gtk.ListBoxRow a, Gtk.ListBoxRow b) {
return mycmp(a, b);
}
}
This widget will never be finalised, even if ::destroy() is called on
it. To ensure it is finalised, I need to override ::destroy() to unset
the sort func, then ensure ::destroy() is called:
private void destroy() {
set_sort_func(null);
base.destroy();
}
My best guess about what is happening here is that that the closure
created when calling set_sort_func(on_sort) is adding a ref to the
object instance, hence when the widget refs the closure in
set_sort_func() a circular ref is created.
I'd argue that GTK is probably correct in not unsetting the sort func
on destroy, for the same reason it doesn't also unset other properties
set by the app.
So is this then a Vala bug? Should a closure created for calling
instance methods in this way use a weak reference to the instance to
avoid exactly this situation? In the case above it is very problematic,
but perhaps if an instance method is passed to an external
function/method like Timeout.add_seconds_full() then that should hold a
non-weak-ref? Perhaps the rule should be "Closures should use a weak
reference to `this` if they are created to be passed to a method on
`this`, but that sounds a bit sketchy, too - what if that method passes
it elsewhere?
//Mike
--
⊨ Michael Gratton, Percept Wrangler.
⚙ <http://mjog.vee.net/>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Gtk.TreeView + Cellrender + text different colors ???
On Fri, Aug 12, 2016 at 10:44 AM, Flavio Danesse <fdane...@gmail.com> wrote: Now I understand that those declared in the fields TreeStore not correspond to the columns. make it work achieved thanks for your attention and apologize for any inconvenience. No problem, it always confuses me after I haven't been using a TreeView for a while. I'm glad you got it working! :) -- ⊨ Michael Gratton, Percept Wrangler. ⚙ <http://mjog.vee.net/> ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Gtk.TreeView + Cellrender + text different colors ???
Hi Flavio, On Thu, Aug 11, 2016 at 11:34 AM, Flavio Danesse <fdane...@gmail.com> wrote: Hello, to see if anyone knows how to do this ? I try pass this code python to Vala: self.get_model (). append ( _iter , [int (key) , text, color] ) The idea is that adding a new element in a treeview , you can specify a particular color in that cellrender I tried a little of everything and nothing seems to work In Vala, you get the newly appended row out first and then set values on it, e.g.: > Gtk.ListStore model = ... > Gtk.TreeIter iter; > model.append(out iter); > model.set(iter, int(key), text, color); HTH, //Mike -- ⊨ Michael Gratton, Percept Wrangler. ⚙ <http://mjog.vee.net/> ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
[Vala] refcounting, signals and closures
Hey all,
I'm trying to track down a memory leak in Geary. I have a custom
subclass of Gtk.ListBox, instances of which are frequently added and
removed from the UI. When it is removed, it is both explicitly
destroyed (widget.destroy()) and all variables containing references to
it are nulled out. Further, I checked its child rows and they are all
are successful removed, destroyed and finalised. Despite all this,
instances of this custom listbox are never finalised, so I have a
memory leak, and probably due to something holding a reference to the
instances still.
The only things I can find that could still be holding a reference are
registered signal handlers, both to instance methods, eg:
> this.row_activated.connect(on_row_activated);
And using closures/lambdas:
> this.size_allocate.connect(() => { check_mark_read(); });
These are never explicitly disconnected in an overridden version of
destroy(), since they should be disconnected when the object is
finalised, by the GObject finaliser.
So, to get to the point, would either of these these hold references to
`this` that prevent it from being finalised?
Ta!
//Mike
--
⊨ Michael Gratton, Percept Wrangler.
⚙ <http://mjog.vee.net/>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Manipulating HTML tag soup in Vala
On Tue, Aug 2, 2016 at 9:04 AM, mar...@saepia.net <mar...@saepia.net> wrote: how about 2-stage processing? Loading HTML into WebKitGtk, dumping DOM (https://webkitgtk.org/reference/webkit2gtk/stable/WebKitWebPage.html#webkit-web-page-get-dom-document) which contains already parsed structure, sanitizing DOM and displaying serialized version of modified DOM for the future use? It should be more secure, too. Thanks for the suggestion. I have thought about this approach, but there's a few things about handling HTML email that makes it tricky though: We want to this to happen without flashing a changing document at the user, we also want to ensure that bulk and junk messages that include bugged remote images and other resources do not lookup and/or load them when the HTML is parsed. Since this would need to be done as an out-of-process WebExtension, it's also all IPC, which is bad. It may all may be possible, but it seems like just parsing and manipulating the markup before shipping it off to WebKit seems like it might be more robust and less work. I'll check with the WebKitGTK guys though. Cheers, //Mike -- ⊨ Michael Gratton, Percept Wrangler. ⚙ <http://mjog.vee.net/> ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
[Vala] Manipulating HTML tag soup in Vala
Hey all, I'm looking for an HTML tag soup library for Geary, that can load tag soup HTML (i.e. possibly malformed) from a stream, allow some manipulation of it, and re-serialise it for display in WebKitGTK. Ideally, a pull-parser API like libxml2's TextReader or StAX[0] would be great, so the whole document does not need to be kept in memory as it is processed. These are the ones I know about: libxml2: - Pros: Has a pull parser API, has a HTML4 tag soup parser, installed everywhere - Cons: Pull parser doesn't work with HTML parser without reading whole document into memory, HTML parser out of date(?) GXml: - Pros: Nice Vala API, uses libxml2 under the hood - Cons: Not a pull parser, loads whole document into memory, doesn't seem to be packaged for any distros, doesn't use the libxml HTML parser(?) Others: - WebKitGTK+: Great tag soup parser, no pull API, doesn't allow manipulating the markup before displaying it (which is the main reason I need to parse the HTML beforehand) - XML Bird: Nice Vala API, but not a pull parser or a HTML parser So none of these seem to completely fit the bill. Are there any other options out there that I have missed? Has anyone else had parse tag soup in Vala? Ta! //Mike [0] - <https://en.wikipedia.org/wiki/StAX> -- ⊨ Michael Gratton, Percept Wrangler. ⚙ <http://mjog.vee.net/> ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] How to override a "class closure for a signal"?
Hi Guillaume, On Thu, Jul 28, 2016 at 9:02 PM, Guillaume Poirier-Morency <guillaumepoiriermore...@gmail.com> wrote: When you override a virtual signal, you only override its default handler, so you don't specify 'signal' in the new method: Thanks for that, so it seems the first approach I suggested was the right one. I'll keep on digging. So is GObject polymorphism is actually implemented using signals? I thought the chaining foo_class structs that happens would have been good enough? //Mike -- ⊨ Michael Gratton, Percept Wrangler. ⚙ <http://mjog.vee.net/> ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
[Vala] How to override a "class closure for a signal"?
Hey all,
I have a subclass of Gtk.ListBox and I'm trying to override
Gtk.Container::gtk_container_set_focus_child on it to prevent its
default behaviour of automatically scrolling to the new focus child.
The docs for that method say this:
This function emits the GtkContainer::set_focus_child signal of
container. Implementations of GtkContainer can override the default
behaviour by overriding the class closure of this signal.
How exactly do I do that? I tried overriding the method using:
public override void set_focus_child(Gtk.Widget? child) { ... }
But even if I do not chain up using a call to
"base.set_focus_child(child)", it seems Gtk.Container's method is still
invoked.
I also tried overriding the signal body using variously:
public override signal void set_focus_child(Gtk.Widget? child) { ... }
public new signal void set_focus_child(Gtk.Widget? child) { ... }
But then valac complains that it "hides inherited signal" in the first
case and "Only virtual signals can have a default signal handler body"
for both.
Any hints? Thanks!
//Mike
--
⊨ Michael Gratton, Percept Wrangler.
⚙ <http://mjog.vee.net/>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Vala app crashing in vprintf on 32-bit arches, not on 64-bit arches
On Fri, Jun 17, 2016 at 7:55 AM, Michael Gratton <m...@vee.net> wrote:
Geary is suffering a bug which is causing it to frequently crash on
32-bit installations, in a place where it doesn't crash on a 64-bit
install. The crash occurs in vprintf, during a call to GLib.debug()
from an async method.
So it turns out the format string was bad ("%d" should have been "%lld"
since a int64 was being passed in) but valac didn't complain - I only
found the issue digging through the gcc output:
/home/mjg/geary/src/engine/imap-engine/imap-engine-minimal-folder.vala:1235:12:
warning: format ‘%d’ expects argument of type ‘int’, but
argument 7 has type ‘gint64 {aka long long int}’ [-Wformat=]
debug("%s do_replay_removed_message: remote_position=%d
unknown in local store "
^
/usr/include/glib-2.0/glib/gmessages.h:170:32: note: in definition of
macro ‘g_debug’
__VA_ARGS__)
^
Bug filed: <https://bugzilla.gnome.org/show_bug.cgi?id=767839>
//Mike
--
⊨ Michael Gratton, Percept Wrangler.
⚙ <http://mjog.vee.net/>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list
[Vala] Vala app crashing in vprintf on 32-bit arches, not on 64-bit arches
Hey all, Geary is suffering a bug which is causing it to frequently crash on 32-bit installations, in a place where it doesn't crash on a 64-bit install. The crash occurs in vprintf, during a call to GLib.debug() from an async method. Looking at the log line on a 64-bit machine, the args passed to it seem valid, and after both having a look at the generated C files on both arches they seem like they should be working fine and appear to be identical. Does this ring a bell for anyone? Should I be looking at libc or glib instead? Details are in <https://bugzilla.gnome.org/show_bug.cgi?id=745165>, best stack trace we have at the moment is here: <https://bug758621.bugzilla-attachments.gnome.org/attachment.cgi?id=329846> Thanks, //Mike -- ⊨ Michael Gratton, Percept Wrangler. ⚙ <http://mjog.vee.net/> ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
