> Just wanted to add that cut-and-paste is pretty freeform on Bugzilla.
Fair enough. That somewhere between a blessing (if you cut and paste a
lot) and a problem (if you need to programmatically make sense of it).
Someone edited that particular bug, btw. Anyone looking now might wonder
what
It is just me, or is the migration mangling bugs?
Compare https://bugzilla.gnome.org/show_bug.cgi?id=765921
to https://gitlab.gnome.org/GNOME/gtk/issues/621
In bugzilla, the cut-and-paste compile commands with output are readable.
In gitlab, they're a mess.
Morten
On Tue, May 1, 2018 at
> On 5 February 2018 at 13:19, Morten Welinder <mort...@gnome.org> wrote:
>>> Considering that you usually stop short of the first step I have to
>>> ask you: what kind of "busywork" have you ever experienced?
>>
>> Here's a sample:
>> https:
as
not rude; it's just that you don't take criticism well, if at all.)
I hope we can agree that bug reporters are volunteer contributors to
the project and that they should be treated with respect.
Morten
On Mon, Feb 5, 2018 at 5:37 AM, Emmanuele Bassi <eba...@gmail.com> wrote:
>
As a general principle, you should only ask bug reporters to do work if you
intend to do something with the answer. Or, with other words, it really is
not nice to keep asking "is that bug still there?" until they get tired of the
busywork and leave in disgust.
With that in mind, I believe it is
You're right. On re-reading that I find that it came out harsher than
it ought to have. My apologies.
Morten
On Thu, Apr 20, 2017 at 7:14 AM, Emmanuele Bassi <eba...@gmail.com> wrote:
> On 19 April 2017 at 13:29, Morten Welinder <mort...@gnome.org> wrote:
>
>>
You are making the situation sound a bit worse than it actually is.
> Not relying on aliasing forbids casting between dissimilar types, which
> rules out "normal" C tricks like casting between GArray and GRealArray
> (where GRealArray starts with the same members as GArray) as a way to have
> a
> Currently, there are 2 rounding functions in the fall backs, round()
> and rint(), with rint() having the better less biased IEEE
> round-to-even behavior for the 0.5 case.
Is known and it is a problem that the fallbacks for round and rint
are only mostly working?
For example, there is a
> When GTK+ breaks the API, it doesn't mean that a higher-level library
> needs to break API too.
That depends.
You are right that a lot of API changes can be hidden.
But if the higher-level library has an API that includes a type
which is being removed, then the API will have to be
changed.
Gtk+ used to support custom widgets. Whenever you were unhappy with
the official
set you would hack up your own. More often than not, this would start
by copying
an official widget's code and do a mass rename of identifiers.
No more.
More and more of the api needed to created widgets is
My plan is to make it a guarantee of the API that both CREATED
and CHANGED events will always be followed by a CHANGES_DONE
hint.
Great plan, but you cannot get that in a meaningful way. Think
creat
write
mmap
close
# Further writes by way of the mapped region
I don't
de...@desrt.ca wrote:
hi,
On Thu, Jan 15, 2015, at 10:49, Morten Welinder wrote:
Great plan, but you cannot get that in a meaningful way. Think
creat
write
mmap
close
# Further writes by way of the mapped region
I don't think you can detect the end of that write
This is the third (fourth) incarnation of a combo box and there is
still opposition to keeping the API stable? That's just crazy.
Matthias' awesomeness aside, why would this be the last time?
Seriously, a change in a widget like this means 20+ hours[*] of
extra work for me as an application
on the contrary: with a new class you'd be sure that the GtkComboBox
widget API is finally stable — as in no changes, except for bug
fixes — which is apparently what you want.
There are three types of widgets in the gtk+ world: (1) active and
non-deprecated, (2) deprecated, and (3) deprecated
Can we keep the api -- function names, etc.?
I.e., could we, for once, do such an upgrade without inflicting
pain on the users? Even at the cost of some pain for
developers.
Morten
On Sat, Dec 27, 2014 at 4:29 PM, Matthias Clasen
matthias.cla...@gmail.com wrote:
On Sat, Dec 27, 2014 at 12:59
I should hope not.
Autotools is indeed the worst possible solution, except for all the
others. (With apologies to Churchill.) But it exists and it is a
known quantity.
It solves problems like generation of tar balls, checking that the tar
balls actually
work, running test suites, checking
For the record, the use of gdk_cairo_create outside of a
begin_paint_region / end_paint pair also seems to work fine on win32.
Morten
On Mon, Jun 23, 2014 at 6:02 PM, Jasper St. Pierre
jstpie...@mecheye.net wrote:
Hey everyone again
I wasn't expecting this much fallout from the change. I was
Argh!
Will the stream of ABI changes never end?
Gnumeric uses this to provide a walking-ant cursor large selected areas -- areas
too big for processing in the normal paint loop.
Morten
On Fri, Jun 20, 2014 at 9:00 PM, Jasper St. Pierre
jstpie...@mecheye.net wrote:
To better support
enum GLogLevel {
... existing, expected values ...
_require_int = INT_MAX
}
That actually makes the whole thing undefined rather than implementation
defined by section 7.1.3 in C99.
M.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
Actually - what's wrong with posix realpath() ?
In my case, not available. And if the aim is portability, see BUGS
in the man page.
M.
On Mon, Nov 25, 2013 at 3:54 AM, Patrick Welche pr...@cam.ac.uk wrote:
On Sun, Nov 24, 2013 at 08:31:21PM -0500, Morten Welinder wrote:
rsvg-base.c:2194:5
rsvg-base.c:2194:5: error: implicit declaration of function
'canonicalize_file_name'
This patch (used for Win32, but there isn't anything win32 specific in there)
with minimal editing should get you going.
Is there some way, as with GtkUIManager, to merge in, and later remove
and replace, menu items? I used this with GtkUIManager to dynamically
populate a menu with items not known at compile time.
Specifically, how does one create menus like Firefox's History and Bookmarks
menus which have
It can be easily fixed in the sense that every application also would then
need to be fixed...
Behdad, you're sitting in your ivory tower and throwing mud at
suggested patches from people who suffer from this bug. What
is the point of that? In the meantime, as Krzysztof points out,
GOption
This code casts GCompareFunc to GCompareDataFunc. As I understand, casting
function pointers in C is not allowed.
You're right, of course, but considering that the signal code
depends heavily on casting function pointers with no obvious
completely standard-sanctioned substitute, there's really
If I'm not mistaken, this was a different kind of breakage that
we engage in a lot of lately: API-incompatible changes on the
unstable branch.
Close, but not quite. This was a case of user updates gtk+ to new
stable 3.x and applications cease to work. No API involved, it's all
a matter of
The breaking of mouse wheel support in gtk+ 3.4 also comes to mind.
(Bug 675089 and others, I'm sure.)
Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
On Sat, Aug 4, 2012 at 3:44 AM, Emmanuele Bassi eba...@gmail.com wrote:
GtkSwitch bugs me. It really should just have been a styling of the toggle
button since it performs the same function with a different look.
it does not perform the same action.
That is a baseless assertion. Of course
=== 4. Which GTK+ widgets break with touch ===
The SpinButton item from above is one example of those.
I really hope the solution is neither remove anything that doesn't work
with touch or parallel widget hierarchy.
GtkSwitch bugs me. It really should just have been a styling of the toggle
This seems like a minor issue compared to GtkGrid 3.0 vs GtkGrid 3.2
incompatibilities. A could of attributes got swapped in-between those
two versions.
Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
7) Ditch theme engines
I like it! No more insanely weird bugs that eventually get
tracked down to a theme engine doing things wrong.
(Weird as in: the last thing people think of when, say,
floating-point numbers get truncated, is that the theme
has changed part of the locale.)
I hope you
Will the new api allow one to write a gui that looks and feels
like it was made with the old api?
Thanks,
Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
What we probably also should do is deprecate one of the two
virtual functions, so people use the same one to clean up everywhere.
That would be a _really_ bad idea.
_finalize gets rid of the last fragments of the object. Since random
code could have obtained refs to the object, the object
Benjamin Otte o...@gnome.org wrote:
But then I looked at [gnumeric] and I realized
it doesn't do anything of that. So I'm inclined to think that what
you're talking about is more about an ideal world that you wish we all
aspired to, but is not in any way related to how people write code in
if (1)
{
glocal_object GFile *file = g_file_new_for_path (/tmp);
glocal_string gchar *basename = g_file_get_basename (file);
g_debug (Basename is '%s', basename);
// look ma' no leaks!
}
This is, of course, cute but I don't think this would actually catch many
In general, we are interested in improving the situation with respect to
Windows builds.
Perhaps then you could take care of bug 614920 (gtk redefines
a system structure type). Obvious patch in comment 4.
Morten
___
gtk-devel-list mailing list
what is the purpose of '(void) (0 ? *(atomic) ^ *(atomic) : 0)'?
Poor man's type check. That expression isn't valid for every
possible atomic.
M.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
Unfortunately this is a pragma
Will C99's _Pragma help? That can be put in a macro.
M.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Currently Gtk applications leak quite a lot when menu items are created
for GtkToolItems. This is because circular links prevent the tear-down:
+---+ (menu_item)+---+ (child)+-+
|GtkToolItem|---|GtkMenuItem|---|GtkAccelLabel|
The core principle that allows most functions to always succeed is
that programming bugs are not thrown, they just terminate the
program.
Havoc, the data doesn't agree with that assertion.
Let's look at numbers:
glib, number of not-crashing on programmer errors:
# find glib -type f -name
you can say that all you want, but it's absolutely *not* a bug.
Of course it is. With this bug, programs crash where they other-
wise could limp on. It's like changing all g_return_if_fail calls
into asserts -- after all, any time one of those hits it represents
a bug somewhere. My log files
If you really want to safely pass a very long text,
you will have to know the font (family and size) then check with stuff
like pango_layout_set_text() and pango_layout_get_pixel_size().
This happened in Gnumeric at some point too. Basically, every time user
supplied string make it into
Once code starts looking like an #ifdef soup it might be time to introduce
a method on, say, the window object.
IMHO, of course.
Morten
#ifdef GDK_WINDOWING_X11
if (GDK_IS_X11_WINDOW (window))
{
timestamp = gdk_x11_get_server_time (gtk_widget_get_window
Any chance of getting reviews of patches for Win32 bugs?
https://bugzilla.gnome.org/show_bug.cgi?id=614920
https://bugzilla.gnome.org/show_bug.cgi?id=619564
https://bugzilla.gnome.org/show_bug.cgi?id=617874
Morten
___
gtk-devel-list mailing list
What global state, for instance?
locale?
As a reminder, setlocale is not thread-safe.
M.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Sorry, I don't understand. Could you explain in more detail?
If you need to run two different windows in two different locales, then
single-instance is not possible. For Gnumeric this happens regularly
due to the world's decimal separator mess.
The reason you cannot do this in a single
On Thu, Feb 24, 2011 at 5:55 PM, Colin Walters walt...@verbum.org wrote:
On Thu, Feb 24, 2011 at 5:15 PM, Morten Welinder mort...@gnome.org wrote:
What actual problem was solved by all this infrastructure to keep just
one instance?
Basically for any application which manipulates private
There are many other reasons to not use single instance.
I agree.
d. Running on a different $DISPLAY. Look and you'll find no end of
complaints over firefox' inability to do this sanely.
e. Running with different locale settings. This happens for Gnumeric
when people want different decimal
Today I found '_gtk_bin_set_child()'
what's wrong with gtk_container_add()?
If _gtk_bin_set_child was needed to subclass GtkBin inside
gtk+ then it is just as needed outside. So your question should
really be answered with the counter question of why is gtk+
not using gtk_container_add?
I plan on branching glib-2-26 early next week and removing GApplication
(and related classes) from the branch.
GDateTime still has API issues. g_date_time_new_full does not
have enough arguments to uniquely identify a time. For example,
one of these is going to be mistaken for the other:
#
The public interface for the following routines are affected by the
patch, however this should not affect any software calling into the GDK
library.
What do you build that assertion on?
Have a look at the program below. With const, the
second foo call causes gcc to complain over types.
That's one of the worst ideas as far as software goes. If an operation takes
1% of your application time and you make it 1000 times faster, you know how
much total faster your application would run? 1.01x faster...
Behdad, that line of argument is only valid for code that is used
by one
As a matter of fact, it is. There is not supposed to be any
replacement for the stuff that says Do not use it. Everything
that has a replacement is however documented.
So please, a little research before bashing perfectly good commits.
How about a research before bashing perfectly good
You probably need to end with something like this
(from Gnumeric):
{
GSList *displays;
gdk_flush();
while (g_main_context_iteration (NULL, FALSE))
;/* nothing */
displays =
There has definitely been a degradation in the ability
of valgrind to find memory leaks in gtk+ applications
over the past, say, 5 years.
I think the basic problem is that there are more singletons
and that gtk+ object hold more pointers to other objects
than they used to.
IMHO, the situation
_gtk_* functions make good sense: the
interaction between widgets and size-groups comes to mind.)
Morten Welinder
PS: I did find a way to set GtkToggleButton::active for Gnumeric. Let us just
describe it as not pretty.
___
gtk-devel-list mailing list
gtk
With this change, it won't break (or add warnings) to any program. It
just removes a warning for programs that do not do the explicit cast,
and get given a const GError.
Really?
Take the program below and notice that the constified prototype
introduces a warning. If used from C++, that would
Does libgsf use the GIO APIs?
It can take a GFile* and treat that as a zipfile. The way you
would read from the zipfile member files would not be GFile*
based. For the output side, turn all that around.
Does that answer your question?
M.
___
FWIW, Sugar uses zip quite extensively to bundle content and software
and we would love to move from using python's zipfile to something
glib-based.
Why all this reinvent-the-wheel effort? libgsf gives you access
to zipfiles and is glib based right now.
Morten
What you are showing there are applications using the file-chooser
incorrectly. In particular they don't set the window size large enough
(or they forget to remember the user-chosen size).
Add a preview: no space left for files.
Add a filter: no space left for files.
Add file format selector:
and confusing
gradual display of network locations (the first time I tried opening
something from my fileserver I thought some of my directories went missing
I think this could actually be improved fairly easily for
all platforms if something (the chooser or backend,
not sure) was more careful
IMO this is now pretty much of a non-issue, since the current GTK
file selection dialog is sufficiently like Windows (but nicer!).
I'm not sure what planet you're living on. The current gtk+
file chooser absolutely stinks! It fails miserably in its
primary task: showing the user what files
This is crazy.
People are actually advocating that thousands upon thousands of applications
need to be changed.
Yes, POSIX allows this particular idiotic behaviour. So what? It probably also
allows free() to do nothing, yet no-one in their right mind would want that. Or
maybe you would be
I think I am in line with what Michael is saying here: there is a
non-trivial risk that littering fsync all over the place will badly
affect existing systems.
The ext4 attitude is interesting, btw. They are saying that
POSIX allows this behaviour so it's your problem. But when
the gcc people
Were there any discussions on fault separation between the
application and the theme engine?
The current state of affairs is that theme engines have a long
record of crashing applications or even changing their functionality.
When that happens, the user blames the application and, sometimes,
What about other window managers? It would be sad to see gtk+
tied directly to a given window manager.
Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Its supposed to be documented in the api docs, at the top of the
synopsis for each section. Of course, the documentation may be
outdated.
This is a farce. Why try to enforce something that does not seem to
have ever been documented? At least not correctly.
On
Someone is pushing changes to the way Gnome modules include header files,
see http://live.gnome.org/GnomeGoals/CleanupGTKIncludes
GTK+ is moving toward a model where it is only allowed to include the
'toplevel'
headers. Only glib.h, gdk/gdk.h, gdk-pixbuf/gdk-pixbuf.h and gtk/gtk.h
can be
I disagree. If we keep gtk_hbox_new() and gtk_vbox_new() around,
we can't change the packing defaults, which is a *huge* benefit
of introducing a new class with new API (GtkBox was abstract before,
so now allowing to instantiate it is in fact a new widget, and
that has to be reflected in
I think the general problem is that if you have a box type that can
change orientation on the fly, what type is it? A HBox or a Vbox?
I cannot actually imagine why I would want such a box, but if you
wanted to you could do
#define GTK_IS_HBOX(w) (GTK_IS_BOX(w)
If all you really want is to change the defaults for box packing, then
why isn't that all you are proposing? It would be a simple 1-line
patch to gtk_box_pack_start_defaults, if I understand things right.
Some thing will break if you do that, but nowhere near as many things
as with changing the
I don't think the minutes reflect what was said in the meeting here.
My understanding was hat the H/V subclasses get deprecated as soon
as the code to enable flipping in their parent classes is in SVN.
If, say, gtk_hbox_new was to get deprecated and disappear in 3.x then
it would be
How is this different from any other deprecated function that got
replaced by another one and will disappear in 3.0?
1. The number of uses of hbox and vbox is *huge*. Working around it
with an #ifdef or two is not going to work well. We're easily talking
hundreds of instances here for a
* Deprecate the H/V split and add orientation instead
+ mitch has a patch deprecating all the H/V classes
+ adds a constructor for base classes
+ defaults can be fixed
+ subclassing is easier
+ change orientation at runtime
+ massive deprecation at branch for 2.90
+ everyone agrees
2008/8/25 Mathias Hasselmann [EMAIL PROTECTED]:
Hi,
The pure existence of GTK_RESPONSE_YES, GTK_RESPONSE_NO, GTK_STOCK_YES
and GTK_STOCK_NO encourages creation of horrible user interfaces.
What a terrible idea!
First, GTK_RESPONSE_YES and GTK_RESPONSE_NO do not imply
much about user
, then that
would be fine. No real work will get done of behalf of those features
anyway.
Morten Welinder
PS: For whatever it's worth, GnuCash also took years to go gtk2.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman
Or maintaining a bunch of deprecated API?
I looked at the log for gtkclist.c and the majority of the changes over the
past five years are a direct consequence of the api having been declared
deprecated. Specifically there is a lot of defining and undefining of
GDK_DISABLE_DEPRECATED going back
So the maintenance burden, to the extent there is one, is _caused_ by
deprecation.
This is ridiculous
Nobody is laughing and you are not reading what I wrote carefully
enough. It really is the elaborate deprecation (as opposed to simply
dropping in a comment and not maintaining the code any
Because const in C is crippled, unlike in C++ where its actually useful.
Soory, but you aren't right:
Yes, he is, but you did not understand him. He was making a language
comment, not an implementation comment.
const in C does not propagate as usefully as you would like. Therefore,
the
That looks like a job for configure. In fact, had it been there, no extra
patch for irix would have been necessary.
Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
There needs to be a 1:1, configurable mapping between any tuple of
these 3 properties and some action within a GTK application.
Why on Earth would you require that mapping be 1:1:? What you need
is that action is a [mathematical] function of the 3-tuple. There is nothing
wrong with invoking
Do you have a case where it would actually make sense to use such
as function? The file name case is an awful one:
1. It's unix-specific. On win32 you can see /foo/bar\baz\bof
2. It fails to distinguish //foo and /foo which, even on unix, are two
different file names.
It seems to me that
This seems to be a solution looking for a problem. I don't think we
need another barrier to participation in gtk+ maintenance.
Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
This comes up regularly for various large values of N.
Just as random thoughts, is there any way that giving a user a list of
100 million items is going to be useful? If you already know that the
user will never see all of the list, why try to display it?
You do not want to do that is not
On Jan 6, 2008 3:43 PM, Mikael Hermansson [EMAIL PROTECTED] wrote:
Hmm just saw that g_build_filename does not work for GIO Uris
its simply strips away separator for example:
g_build_filename(file:///, g_get_home_dir(), foobar.txt, NULL)
will be:
file:/home/user/foobar.txt
It's hard to
The practical use of such a function is to give the user a general idea of
the size. Hence a 2.4% (k), 4.9% (m), or 7.4% (g) difference will
not change the picture.
However, something people need the full story. Therefore, the friendly
application using such a function should probably consider
Specially as you can use #undef in your C code, when stuck with a
platform doing such stupidities...
Aha, a member of the standards-don't-apply-to-me school, :-)
Yes, you might #undef, but then you would not be able to use the
corresponding library function anymore. For example, if a platform
I added an extra check for -write != NULL in the splice case (because
write() already did that) and commited.
I would be to avoid having struct members called write. That is a reserved
symbol and if the C library decides to use a macro you will have some very
interesting effects.
Morten
I notice that there are no padding members in, for example,
GtkCellLayoutIface. Adding members therefore will change the
struct size which sounds like a clear ABI change to me.
Anyone who did
typedef struct {
GtkCellLayoutIface clif;
Bar baz;
} Foo;
is going to see random crashes when
Whyever would you do that? Such a struct would never be useful.
It is a simple use of an existing type in the API. I can create my own
instances of such a type, even if I cannot hand them off to anything
GObject related. I could store signal handlers there, for example.
Bottom line: a
nobody has to use this syntax. you can stick to the ever simple:
g_assert (foo bar);
however if you want the value of 'foo' and 'bar' be printed out, instead
of just the value of (foo bar) which would be 0 or 1, then there are
no other means than using something simialr to:
That's pretty much a no-go.
g_assert_warning is marked G_GNUC_NORETURN.
If you return from such a function, there is no telling what incorrect
assumption the
following code was compiled with, i.e., things that the compiler thought were in
registers all of a sudden are not. Crash. Burn. Toast.
I would find it useful if such an undo system would do away with the stack
view of things and use the back-in-time view that Emacs uses.
For example, if we have
Do A, Do B, Do C, Undo C, Do D
then it should be possible to rewind history to the point where C was done.
Morten
The thing I miss from your list is how to make sure themes' code does not
crash the innocent application into which they get loaded.
There have been several rounds of obscure bug reports for Gnumeric that
basically came down to theme code bugs.
Morten
Are there other platforms on which Gdk may have more than one screen?
Or if multiple X servers are running, with multiple copies of Gnome,
do they still share the same gdk?
Gnumeric under X can use multiple screens (or displays for that matter).
It's quite useful to have multiple screens if
I was thinking more of gtk+ blacklisting the theme, but nevermind that.
4. User updates gnumeric, and can't run it anymore because it barfs on
that engine. He still risks crashes in other apps.
Not quite. Gnumeric starts with default theme, looks strange, but works.
M.
In light of bug 438456, is there (or should there be) a way to
blacklist a certain
theme engine for a certain version range?
Bug 438456 causes memory corruption in any gtk+ application it is applied to.
Morten
___
gtk-devel-list mailing list
I don't see how this is different from any other memory corrupting bug
in, say, a library.
From a technical standpoint it is not.
However, a theme is a library that is loaded into your application by
the end-user.
Even if he is not particularly aware of doing so.
The application programmer
user_type and user_data which I proposed doesn't make too much sense, it's
also difficult to support since you can't (AFAICT) use a GValue as user data.
It would be marginally useful for providing constant user data like...
* Strings: oink
* Translated strings: _(Moo!)
* Integers:
Since it accepts a nick, name or number, it's using
g_enum_get_value_by_nick/name internally.
...in which case it belongs in glib.
Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
On 4/2/07, Jakub Steiner [EMAIL PROTECTED] wrote:
Hi gtk+ developers.
I propose a replacement of the current gtk stock icons with newly
created artwork[1].
True or False: if you do so, applications that use the occasional own
icon will en up looking wrong with the new icons. (And if we fix
1 - 100 of 130 matches
Mail list logo
