signal for closing app

[Krzysztof]

I'm the very beginner in GTKmm.
I design a simple interface in Glade. The application itself is written 
in C++.


Which signal should I choose and which handler should I specify in 
File-Quit menu item to have the same action as clicking the X at upper 
right corner of window?

How should I make it working in my application?

--
Regards
Krzysztof J.

___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

glib - main event loop

[Krzysztof]

How to get idle event source  called in main event loop? I do the 
following:

my idle function is:

static gboolean
idle ( gpointer data )
{
g_print ( "Idle called\n" );
if ( counter1 == 0 && counter2 == 0 )
{
g_main_loop_quit ( ( GMainLoop * ) data );
return FALSE;
}
else
return TRUE;
}

The variables counter1 and counter2 reach 0 after some time of execution.

I add this source this way:

g_idle_add ( idle, mlp );

where

GMainLoop *mlp;

is loop which is run.

Even if all sources end with G_SOURCE_REMOVE the idle source is never 
called.


--
Regards
Krzysztof J.

___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

GSource callback

[Krzysztof]

The documentation for Glib function /g_source_set_callback ()/ tells this:
"The exact type of /|func|/ depends on the type of source; ie. you 
should not count on /|func|/ being called with /|data|/ as its first 
parameter."

What does it exactly mean? The callback function has the type:

gboolean 
<https://developer.gnome.org/glib/stable/glib-Basic-Types.html#gboolean>  (*GSourceFunc)  (/|gpointer 
<https://developer.gnome.org/glib/stable/glib-Basic-Types.html#gpointer> 
user_data|/);


So what should I expect as a parameter when glib calls my callback 
function with a /gpointer/ data. How can I find *my* data?


--
Regards
Krzysztof J.

___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: glib - main event loop

[Krzysztof]

Thanks Chris. It worked.
Does it mean that idle source can be effectively added to global loop 
only? Can't I have idle source in other contexts?


On 03/16/2016 01:46 PM, Chris Vine wrote:

On Tue, 15 Mar 2016 20:03:20 +0100
Krzysztof <k...@limes.com.pl> wrote:

On 03/15/2016 12:54 AM, Chris Vine wrote:

  From your incomplete code it is impossible to say.  Do you call
g_main_loop_run()?  How did you construct your main loop?

Try to post a complete (but minimal) example of what you are doing.

Chris
___

Thanks for reply. Here is the complete code:

[SNIP]

I do not think that can reasonably be described as a minimal example.

However, you have not constructed a default main loop, which is what
g_idle_add() will execute in.  Set mcx to NULL and don't call
g_main_context_new() and your code should work.

Chris


--
Regards
Krzysztof J

___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: GsourceFuncs.finalize-solved

[Krzysztof]

/finalize/ was called after call of /g_source_destroy/ and 
/g_source_unref/. Only if both were called /finalize/ was too.


On 03/31/2016 11:27 PM, Krzysztof wrote:

When the /finalize/ member function is called? I can't get it to.
--
Regards
Krzysztof J.


___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list


--
Regards
Krzysztof J.

___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

GSource count

[Krzysztof]

Is it reasonable to have thousands of sources added to event loop? I 
mean efficiency of computing. I don't know how this factory of event 
consuming exactly works.

A population of artificial cells may be an example.

--
Regards
Krzysztof J.

___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

GsourceFuncs.finalize

[Krzysztof]

When the /finalize/ member function is called? I can't get it to.

--
Regards
Krzysztof J.

___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

loops and contexts

[Krzysztof]

Is there a reason to have more than one MainContext or more than one 
MainLoop? Or is it more appropriate to add event handlers to one 
application main loop (I mean GtkApplication)?


--
Regards
Krzysztof J.

___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: loops and contexts

[Krzysztof]

Having said this, if you have a simple simulation program written based 
on GTK+ it's reasonable to engage one main loop for windowing and the 
other for simulation processing which results are shown in a window. Am 
I right? But what about context? Should it be the one main or is it 
better to create new one?


Regards
Krzysztof J.

On 05/08/2016 03:36 PM, Paul Davis wrote:
Also, worth differentiating between 1 main loop per thread + multiple 
threads, and multiple recursive main loops per thread.


Modal dialogs involve a recursive main loop, but it runs in the same 
thread as the normal main loop does (since it runs "inside" the "real" 
main loop).


An application like Ardour runs N main loops in N threads, with each 
thread dealing with a different type of event source. We do not 
multiplex the event sources into the normal main loop, because we do 
not want the GUI behaviour potentially interferred with by the demands 
of these other UI control systems. Not many applications require this 
design.



On Sat, May 7, 2016 at 6:10 PM, Ben Iofel <iofel...@gmail.com 
<mailto:iofel...@gmail.com>> wrote:


Dialogs, for example, have their own main loop.

Generally, though, you will have one main loop (gtk's loop) even
for multiple windows in your app.

On Fri, May 6, 2016 at 4:11 PM, Krzysztof <k...@limes.com.pl
<mailto:k...@limes.com.pl>> wrote:

Is there a reason to have more than one MainContext or more
than one MainLoop? Or is it more appropriate to add event
handlers to one application main loop (I mean GtkApplication)?

    -- 
Regards

Krzysztof J.

___
gtk-list mailing list
gtk-list@gnome.org <mailto:gtk-list@gnome.org>
https://mail.gnome.org/mailman/listinfo/gtk-list



___
gtk-list mailing list
gtk-list@gnome.org <mailto:gtk-list@gnome.org>
https://mail.gnome.org/mailman/listinfo/gtk-list




___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

menu question

[Krzysztof]

I'm beginning to manually set up application menu. I've done this:

void SimApp::on_startup()
{
Glib::RefPtr appmenu = Gio::Menu::create();
Glib::RefPtr itemnew = Gio::Menu::create();

add_action("filenew", sigc::mem_fun(*this, ::on_file_menu_new));
itemnew->append("New", "filenew");
appmenu->append_submenu("File", itemnew);
set_menubar(appmenu);
}

The "New" item under File menu is dimmed. What's missing in that code?


--
Regards
Krzysztof Jasienski

___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: menu question

[Krzysztof]

I think it's solved. I changed the name of action to "app.filenew" and 
it works.


There is another question:

What to do with the warning

"Gtk-WARNING **: GtkMenuBar 0x1586160 is mapped but visible=1 
child_visible=1 parent gtkmm__GtkApplicationWindow 0x14c8260 mapped=0"


Pozdrawiam
Krzysztof Jasienski

On 08/18/2016 11:49 PM, Krzysztof wrote:

I'm beginning to manually set up application menu. I've done this:

void SimApp::on_startup()
{
Glib::RefPtr appmenu = Gio::Menu::create();
Glib::RefPtr itemnew = Gio::Menu::create();

add_action("filenew", sigc::mem_fun(*this, 
::on_file_menu_new));

itemnew->append("New", "filenew");
appmenu->append_submenu("File", itemnew);
set_menubar(appmenu);
}

The "New" item under File menu is dimmed. What's missing in that code?




___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Gio::Menu question

[Krzysztof]

I tried to write a similar program to that I found at: 
https://github.com/GNOME/gtkmm-documentation/tree/master/examples/book/application/app_and_win_menus


The problem is that menu does not show itself but menu items do when I 
click the place the menu bar should appear. How to make menu bar 
visible? Below is my program. I would appreciate any help because I'm 
struggling for a long time with the case.



main.cpp

#include 
#include 

#include "simwdg.h"



int main ( int argc, char **argv )
{
Glib::RefPtr app = (Glib::RefPtr)SimApp::create ( );

app->run(argc, argv);

return 0;
}

---

simwdg.h

#ifndef SIMMENU_H
#define SIMMENU_H

#include 


class SimAppWnd;

class SimApp : public Gtk::Application
{
public:
SimApp ( );
virtual ~SimApp();

public:
virtual void on_startup();
virtual void on_activate();

static Glib::RefPtr create();

public:
bool on_delete(GdkEventAny* event);
void on_file_menu();
void on_file_menu_new();
void on_file_menu_close();

private:
SimAppWnd *wnd;
};



class SimAppWnd : public Gtk::ApplicationWindow
{
public:
SimAppWnd();
virtual ~SimAppWnd();

private:
Gtk::DrawingArea darea;

public:
bool on_draw(const Cairo::RefPtr& cr);
void on_file_menu_close();
};

#endif // SIMMENU_H

--

simwdg.cpp

#include 

#include "simwdg.h"



SimApp::SimApp ( ) : Gtk::Application ( "KJ.Projects.SimApp" )
{
Glib::set_application_name ( "App" );
}

SimApp::~SimApp()
{

}

void SimApp::on_startup()
{
Glib::RefPtr menu = ( Glib::RefPtr ) 
Gio::Menu::create(),
wmenu = ( Glib::RefPtr ) 
Gio::Menu::create(),
fmenu = ( Glib::RefPtr ) 
Gio::Menu::create();


std::cout << "Startup called" << std::endl;
Gio::Application::on_startup();
add_action ( "filenew", sigc::mem_fun ( *this, 
::on_file_menu_new ) );
add_action ( "fileclose", sigc::mem_fun ( *this, 
::on_file_menu_close ) );


menu->append ( "New", "app.filenew" );
set_app_menu ( menu );

fmenu->append("Close", "app.fileclose");
wmenu->append_submenu("File", fmenu);
set_menubar(wmenu);
}

void SimApp::on_activate()
{
std::cout << "Activate called" << std::endl;
Gio::Application::on_activate();

wnd = new SimAppWnd;
add_window ( *wnd );
wnd->signal_delete_event().connect ( sigc::mem_fun ( *this, 
::on_delete ) );

hold();
wnd->show_all();
}

Glib::RefPtr< SimApp > SimApp::create ( )
{
std::cout<<"Create application"<<std::endl;
return Glib::RefPtr ( new SimApp() );
}

bool SimApp::on_delete ( GdkEventAny* event )
{
Gtk::ApplicationWindow *win= ( Gtk::ApplicationWindow * ) 
get_active_window();


win->set_show_menubar ( false );
release();
return false;
}

SimAppWnd::SimAppWnd()
{
Gtk::ApplicationWindow();
set_title ( "Simulation" );
set_default_size ( 300, 300 );
}

SimAppWnd::~SimAppWnd()
{

}

void SimApp::on_file_menu()
{
std::cout << "File menu" << std::endl;
}

void SimApp::on_file_menu_new()
{
std::cout << "(app) File menu new" << std::endl;
}

bool SimAppWnd::on_draw ( const Cairo::RefPtr< Cairo::Context >& cr )
{
Gtk::Allocation allocation = get_allocation();
const int width = allocation.get_width();
const int height = allocation.get_height();

std::cout << "On draw: " << "w: " << width << " h: " << height << 
std::endl;


// coordinates for the center of the window
// int xc, yc;
// xc = width / 2;
// yc = height / 2;
//
// cr->set_line_width ( 10.0 );
//
// // draw red lines out from the center of the window
// cr->set_source_rgb ( 0.8, 0.0, 0.0 );
// cr->move_to ( 0, 0 );
// cr->line_to ( xc, yc );
// cr->line_to ( 0, height );
// cr->move_to ( xc, yc );
// cr->line_to ( width, yc );
// cr->stroke();

return true;
}

void SimApp::on_file_menu_close()
{
std::cout << "(app) File menu close" << std::endl;
}


--
Regards
Krzysztof

___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

What class with signals capabilities?

[Krzysztof]

Hi,

I'd like to make a class with signaling capabilities (receiving and 
emitting signals) under gtkmm. What class is the best to derive from? 
Gio::SimpleActionGroup or something else?


--

Regards
Krzysztof Jasieński

___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Effective size of drawing area

[Krzysztof]

Assume that:

window default size is 300x300

window has box with menu bar and drawing area:

box = new Gtk::Box(Gtk::ORIENTATION_VERTICAL);
box->pack_start(menuBar, Gtk::PACK_SHRINK);
box->pack_start(*darea, Gtk::PACK_EXPAND_WIDGET);

What is and how to determine the size of area where I can actually do 
all drawing?



--
Regards
Krzysztof J.

___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Old Windows-specific bug in GOption

[Krzysztof Kosiński]

Hello

First, I would like to send a big thank you to Murray Cumming for
committing the fix for the lingering libsigc++ accumulator bug! It
will allow everyone to write more powerful signals code.

There's a second serious bug that impacts Inkscape, and it's one of
the reasons we still uses libpopt for option parsing. This time it's
in Glib.
https://bugzilla.gnome.org/show_bug.cgi?id=522131

The comment thread in the bug is rather long, so I will outline what's
the problem. I'll call it The Immigrant Problem, since it is most
likely to impact people who changed their country of residence.

On Windows, the command line passed to main() is in the system
codepage (glib term: locale encoding). Usually it's some
ASCII-compatible single byte encoding, but on Asian systems it might
be multibyte. It's all fine when the user only opens files with names
in his local language. Problems start to happen when, for example,
someone tries to open Russian-named files on an English copy of
Windows. To be more precise, it happens whenever someone tries to open
a filename that contains characters not representable in the locale
encoding.

The arguments of main() simply do not contain the information needed
to unambiguously locate the Russian-named files. If there are two
plain text files with three-character Russian names in one folder,
both of them will be passed to main() as ???.txt and there is no way
to tell which one should be opened. It means the arguments of main()
are useless in this case.

Right now, GOption assumes that the argv passed to it is in locale
encoding and converts it to UTF-8 when parsing, so even if we have the
Unicode command line from somewhere else, we cannot parse it using
GOption. If we converted the Unicode command line to locale encoding,
we would lose the necessary additional information it contains. More
complicated tricks undermine the merit of using GOption at all.

The Unicode command line can be retrieved on Windows using one of the
following ways:
- GetCommandLineW() - functions retrieves the full command line as a
single string as it was entered, without shell expansion.
- __wargv - undocumented global variable equivalent to __argv that
contains argv in UTF-16.
- _wmain() - undocumented alternative entry point that receives UTF-16
argv. I heard that MinGW doesn't support it, though didn't check it.

There a few possible solutions to this problem:
1. On Windows, ignore the arguments of g_option_context_parse, and use
__wargv instead.
2. Same as above, but use the new behavior for a new method and
deprecate g_option_context_parse.
3. Introduce a helper function that retrieves UTF-8 command line
arguments, based on global variables and arguments of main(), and
provide g_option_context_parse_utf8 method which takes UTF-8 encoded
argv.
4. Same as 3, but use an option context property to select the input encoding.
5. Introduce a method that always parses argv based on global data.
6. Same as 1, but try to guess whether the passed argv was modified by
comparing it to __wargv. If it wasn't, use __wargv.

Each has a downside:
1: Can break programs that modify the arguments of main() before
passing them to GOption.
2: Requires changes to existing code and disallows modifying argv
before parsing when using GOption (probably not a bad thing).
3: Requires changes to existing code and using a non-obvious function
that does nothing on Gnome's primary platform (Unix), so it's possible
most programs will not use it and remain broken on Windows until
someone discovers this relatively rare bug for each of them.
4: Overloads one method to take 2 different types of data.
5: Requires depending on highly platform-specific features. There is a
__wargv equivalent called __libc_argv, which works at least on Linux,
but probably not on other Unixes.
6: Still doesn't fix the problem if argv is modified, causing
unobvious breakage.

I would favor solution #2, since it's the simplest and least probable
to cause confusion, but bug commenters apparently wanted to go with
#6. I sent a few patches implementing #6 but they weren't committed.
What do others think about this?

Regards, Krzysztof Kosiński
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Old Windows-specific bug in GOption

[Krzysztof Kosiński]

If anyone is interested in fixing this highly annoying bug that
prevents serious projects from using GOption on Windows, please see
the new patch I created:
https://bugzilla.gnome.org/show_bug.cgi?id=522131

It defines a new structure, GCommandLine, that can be created from
various sources. The default constructor (g_command_line_new) does
the right thing for all platforms.

Regards, Krzysztof
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: cross compiling GTK+ on Linux for Windows

[Krzysztof Kosiński]

2010/6/14 Tor Lillqvist t...@iki.fi:
 For anybody new looking into it, I certainly recommend using
 cross-compilation. Have a look at the spec files for the
 cross-compiled GTK+ stack (and much more) for Windows in the OpenSUSE
 Build Service. See
 http://download.opensuse.org/repositories/windows:/mingw:/win32/openSUSE_11.0/src/
 for the source RPMS, and sibling directories for noarch RPMs
 containing in fact Windows binaries. My plan is that eventually the
 Windows binaries offered from www.gtk.org / ftp.gnome.org will come
 from the OpenSUSE Build Service projects.

Is there any sanctioned way of doing this on Debian?
Regards, Krzysztof
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

GtkRange API is incomplete

[Krzysztof Kosiński]

Hello

Here is my use use case (in Inkscape). I have a set of sliders
(GtkScale) that control some values in the document. I want to update
the view of the document in real time, but only push the change on the
undo stack when the drag is finished. But the only signal I can
connect to is value-changed. When I connect to it, I have only two
choices:
1. Update policy GTK_UPDATE_DISCONTINUOUS. This will give me correct
undo behavior but won't update the display in real time.
2. Update policy GTK_UPDATE_CONTINUOUS. This will update the display
correctly but will flood the undo stack with partial changes.

The problem would be solved if there was some additional signal that
would only be emitted when the user finishes the drag, or when the
slider is moved using the keyboard. It could be called value-set.
Essentially, it should be emitted after the value-changed signal
whenever the value-changed signal would be emitted if the update
policy was GTK_UPDATE_DISCONTINUOUS.

Here's the relevant bug report from our tracker.
https://bugs.launchpad.net/inkscape/+bug/579932

Regards, Krzysztof
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkRange API is incomplete

[Krzysztof Kosiński]

W dniu 27 lipca 2010 18:06 użytkownik Alberto Ruiz ar...@gnome.org napisał:
 Hi there,
 You can just connect to the GtkRange's GtkAdjustment value-changed
 signal for the view update.

The problem is not the view update but the undo stack update. It
should only be updated when the drag is finished.

Regards, Krzysztof
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkRange API is incomplete

[Krzysztof Kosiński]

W dniu 27 lipca 2010 23:32 użytkownik Sven Neumann s...@gimp.org napisał:
 You could implement undo compression as we do in GIMP. Multiple
 consecutive position changes are compressed into a single undo step.
 This can be easily implemented by looking at the top-most step on the
 undo stack and checking if it is of the same type as the step you are
 pushing.

We also have undo stack compression (or rather coalescing). I
discovered there was an error in one of our internal functions that
required the undo keys to be constant strings, and the affected dialog
used dynamically generated keys. This prevented undo event coalescing
from working.

Anyway, thanks for your suggestion, because it pointed me in the right
direction.

Regards, Krzysztof
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: AC_MSG_RESULT(patching libtool to fix HIDEOUS BREAKAGE) [was Re:dconf 0.5]

[Krzysztof Kosiński]

2010/8/4 Havoc Pennington h...@pobox.com:
 automake is fine, but libtool is a real problem. It seriously
 lengthens compile/install times in a way that's probably wasted tens
 of thousands of developer hours over the years, *at least*. In all
 honesty, most likely any of us who write a lot of C code could get
 back the time spent patching libtool out of automake *just in time
 saved personally*, let alone time saved for everyone else.

I have used Waf for some time and it changed my opinion about
Autotools and CMake.

Only demigods can really understand the inner workings of Autotools to
the point of being able to meaningfully modify them, and getting it to
work on Windows is an exercise in masochism. CMake's scripting
language is incredibly unexpressive and it takes lots and lots of code
to do anything moderately complicated. Meanwhile Waf is
architecturally quite simple and allows you to write concise scripts
in Python. It's also infinitely faster than SCons.

Of course, it doesn't have all the features required by GNU projects
(for example tarball creation is very limited), but I think it would
be more productive to enhance Waf to the point it's a feasible
Autotools replacement, rather than wasting time on the current
mainstream choices.

Regards, Krzysztof
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: AC_MSG_RESULT(patching libtool to fix HIDEOUS BREAKAGE) [was Re:dconf 0.5]

[Krzysztof Kosiński]

2010/8/5 Simon McVittie simon.mcvit...@collabora.co.uk:
 ... but it appears to be distribution-hostile, at least in its current state:

    http://www.mail-archive.com/debian-de...@lists.debian.org/msg281373.html

 Yes, autofoo also results in embedding a copy of itself in tarballs, but
 distributions who have a newer/more-bugfixed version of autofoo than the
 upstream can generally autoreconf it. Waf doesn't seem to be upgradable in a
 similar way.

My take on this is:
1. Several projects using Waf had the binary in their tarball to
avoid any possible incompatibilities between Waf versions
2. Debian knew better and tried to replace them with one single copy the script
3. Build breakages ensued
4. Projects and Waf upstream got angry about this
5. Maintainer used some weird threats to get the system-wide Waf
package out of Debian
6. Debian attempted a compromise (e.g. they still knew better) but
finally capitulated
7. Now everyone thinks that Waf maintainer is uncooperative

The problem appears to be conceptual: Waf upstream regards Python as
the actual build system and the Waf binary as a local component
similar to the configure script, while Debian thinks Waf is like the
Autoconf or Automake executables.

Waf is also upgradable, but is not as API stable as Autotools. In
most cases you can drop a new version of the Waf binary into your
project directory and it will build without modification, but in some
cases it won't, so one ships the version that was verified to work. By
the way: why it's OK to bundle parts of build system code (like
libtool, m4 macros, preprocessed configure script, etc.) in the
tarball, but it's not OK to bundle the *entire* build system code?

In any case, I'm not saying that current Waf is better than current
Autotools, but that its model of execution (execute user's Python
script that defines the targets to build, use the Python interpreter
to spawn tasks) is superior to Autotools (preprocess Makefile.am,
preprocess shell script, run shell script, run make to spawn tasks).
I want this model, not Waf in particular.

 See this mail from Piotr Ożarowski (who packages a large proportion of the
 Python modules in Debian), which lists use waf as build-system alongside
 release different tarballs with the same version number (!) among things
 to avoid:

    http://www.mail-archive.com/python-...@python.org/msg47681.html

It looks out of place on this list. Comparing Waf use to version
number aliasing is dramatizing. Debian people should get over the
assumption that every respectable build system should work like
Autotools or CMake.

Regards, Krzysztof
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[GObject Introspection] Getting style colors using GTK and Python

[Krzysztof Klinikowski]

Hello. I need to get colors from used GTK style. Later, using PyGTK I
do things like:

def get_theme_colors(w = gtk.Window()):
  w.realize()
  style = w.get_style()
  output = {}

  for i in [base, text, fg, bg]:
c = getattr(style, i)[gtk.STATE_NORMAL]
output[i] = Color.from_gtk_color(c)
c = getattr(style, i)[gtk.STATE_SELECTED]
output[%s_selected % i] = Color.from_gtk_color(c)

  return output

Now im trying to do using PyGI:

def get_theme_colors(w = gtk.Window()):
w.realize()
style = w.get_style()
output = {}

for i in [base, text, fg, bg]:
print style.bg
c = getattr(style, i)[gtk.StateType.NORMAL]
output[i] = Color.from_gtk_color(c).hex
c = getattr(style, i)[gtk.StateType.SELECTED]
output[%s_selected % i] = Color.from_gtk_color(c).hex

return output

But something like style.bg always prits me:

Segmentation fault (core dumped)

Question is why? Should I do that in different way? I have no idea.
Could anyone help me?
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Patch review needed

[Krzysztof Kosiński]

Hello

There's a patch available for bug #522131 which severely affects the
usability of GOption on Windows. There is a patch available, but it
needs review. Can one of the developers look at it? It would enable a
few cross-platform applications to drop a dependency on popt.

https://bugzilla.gnome.org/show_bug.cgi?id=522131

Regards, Krzysztof
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Glib: a Win32 discussion

[Krzysztof Kosiński]

2011/4/6 Kean Johnston kean.johns...@gmail.com:
 Everyone,

 WARNING: long, detailed message. If you don't care about Win32, move on.

Other annoying Windows issues specific to glib:

1. GOption fails hard for filenames which are in a language different
than your Windows. E.g. Chinese or Russian filenames on English
Windows. The arguments passed to main() contain ? in place of the
Chinese / Russian characters and that's just not enough information to
correctly identify the file. More detail in the bug:
https://bugzilla.gnome.org/show_bug.cgi?id=522131

2. GApplication. Mentioned in the mail. This functionality is
traditionally implemented using named mutexes and shared memory.
http://stackoverflow.com/questions/2285110/restrict-application-to-one-instance-per-shell-session-on-windows

3. GSettings using the registry. This means portable apps (in the
sense of apps that you can carry with you on an USB stick:
http://portableapps.com/) cannot use it, because they have to store
the settings somewhere on the USB stick, not in the registry. It
should be possible to use dconf on Windows.

Regards, Krzysztof
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Glib: a Win32 discussion

[Krzysztof Kosiński]

2011/4/10 Tim Evans t.ev...@aranz.com:
 A combination of GetCommandLineW and CommandLineToArgvW can get you the
 arguments as wchar_t strings which could then be converted to utf8. Is this
 just something that glib needs to provide a convenience function for?
 g_win32_get_utf8_argv() maybe?

This is not about a convenience function. The real problem is that
GOption cannot parse UTF-8 argument lists. It will always consider the
argv to be in locale encoding, and the locale encoding cannot
accurately represent filenames on Windows. The input encoding for
GOption should be switchable at runtime.

Once GOption can parse UTF-8, the convenience function to get the
Unicode argv on Windows can be written. However, GetCommandLineW /
CommandLineToArgvW do not work, because globs are not expanded. You
need to use the function __wgetmainargs with glob expansion set to
true, the way it is used in glib/gspawn-win32-helper.c.
http://msdn.microsoft.com/en-us/library/ff770599.aspx

Regards, Krzysztof
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Resource framework, relocatability (was Re: Glib: a Win32 discussion)

[Krzysztof Kosiński]

2011/4/18 Alberto Ruiz ar...@gnome.org:
 So yeah, .RPM/.DEB is absolutely fine for system level components
 (platform, shell...). But for applications, I have to say I really
 don't agree at all that it is the right mechanism, unless you come up
 with a sandboxed approach for apps installed by the user.

Apparently what's needed is some kind of per-user package manager.

Most things an application will need can be done by manipulating stuff
in the home directory. This includes things such as browser plugins. I
guess it would be best to ensure that application authors can use
every desktop feature without manipulating any root-owned files.

Automatically adding ~/bin to PATH if it exists and the .local
hierarchy are examples of this approach.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: About gsettings aborting on unkown schemas

[Krzysztof Kosiński]

2011/5/27 Havoc Pennington h...@pobox.com:
 Config schemas that contain type checking and default values are part
 of the program; the program is either incorrect, or redundant in a way
 likely to create bugs, without the schemas. If schemas were just docs
 or something, it would be a different situation.

I think it's OK for schemas to be mandatory for programs, but problems
start when the program has several optional modules or plugins with
each having their own schemas, and the main program does not require
any of those optional modules to meaningfully work. So g_settings_new
unconditionally aborting might not be a bug, but it is very
inconvenient for the programmer.

I think the following could be done to fix this problem:
a) provide a function called g_settings_schema_exists that would check
whether creation of GSettings for a given schema name would succeed
b) provide g_settings_try_new as suggested before

Regards, Krzysztof
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Updated GTK+ 2.24.5 binaries (and bundle)

[Krzysztof Kosiński]

2011/7/12 Dieter Verfaillie diet...@optionexplicit.be:
 I have been dreaming of having an msys-python port though (considered by
 most to be even more exotic than cross-compiling Python itself, I guess).
 Would make jhbuild, but also other tools written in Python that need to
 run at build-time like gi-scanner, much more reliable. And we'd be able
 to get rid of loads of subprocessing workarounds/bugs...

I worked on a cross platform build system for Inkscape. Currently we
use Autotools on Unix-like platforms and a custom build tool on
Windows. because we decided that we cannot depend on MSYS. Here are my
$0.02:

The whole raison d'etre of MSYS is to allow Autotools to work. Once
you get rid of Autotools, you no longer need MSYS. And if you are
serious about portability, you need to get rid of Autotools anyway,
because the last available version of MSYS Perl can no longer run the
recent automake releases. This makes building from a source checkout
(not a tarball) on Windows impossible.

Regards, Krzysztof
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Updated GTK+ 2.24.5 binaries (and bundle)

[Krzysztof Kosiński]

W dniu 12 lipca 2011 19:17 użytkownik Dieter Verfaillie
diet...@optionexplicit.be napisał:
 Fair enough, using a custom build tool on Windows is your choice,
 not mine ;)

Maybe I wasn't clear enough. I worked on *getting rid* of this
Windows-only build tool, but didn't succeed yet. FWIW, Waf appears to
work best for me.

 Also msys-perl has been updated. Check this thread:
 http://article.gmane.org/gmane.comp.gnu.mingw.user/36263
 There a good chance most intltool vs (Active)Perl hacks/workarounds
 described all over the net to get a working MinGW/MSYS build system
 for the GNOME platform going are no longer valid.

Looking at the timestamp of the message, it looks like I last tried
building Glib from a source checkout some time before this updated
Perl was released, so my information was outdated.

Regards, Krzysztof
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Deprecated symbols list

[Krzysztof Kosiński]

Hello

I recently finalized the removal of all deprecated Glib symbols from
Inkscape [1]. Now I'm exploring removing some of the deprecated GTK
symbols.
This site [2] has a link to a list of deprecated symbols in HTML
format, but there is no text file which could be used with the
provided egrep command.

Can I generate the relevant gtk-deprecated-symbols.txt in some
automated way from GTK sources?

Regards, Krzysztof

[1] https://bugs.launchpad.net/inkscape/+bug/367606
[2] http://live.gnome.org/GnomeGoals/RemoveDeprecatedSymbols/GTK%2B
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Fwd: Plans for GTK+ Bundles for win32 and win64?

[Krzysztof Kosiński]

2011/9/8 Kean Johnston kean.johns...@gmail.com:
 Note that many of us build programs with MinGW, so for such suite to be
 useful, it should provide GCC-compatible import libraries.

 If MinGW can't use standard microsoft import libraries that (from my
 perspective) is Someone Else's Problem.

If you have the DLL, you can generate the MinGW-compatible import
library using the pexports and dlltool utilities. I'm not sure if i
works with all DLLs, but it definitely does with the ones in the
binary Windows bundle.
http://wiki.inkscape.org/wiki/index.php/Inkscape_Devlibs#Generating_import_libraries_from_DLLs

Regards, Krzysztof
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: _wstat on Windows (actually stat stuff in general)

[Krzysztof Kosiński]

2011/9/26 Jernej Simončič jernej|s-gm...@eternallybored.org:
 Won't that fail on filenames that have characters outside of the active
 codepage instead?

You can use g_win32_locale_filename_from_utf8() to obtain a short
filename (8.3) that will refer to the filename with unrepresentable
characters. You can then use it with narrow functions of the Windows
API. This will not work if short filename generation is turned off in
the registry. I don't know whether it's still turned on by default.

Regards, Krzysztof
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: _wstat on Windows (actually stat stuff in general)

[Krzysztof Kosiński]

2011/9/26 Kean Johnston kean.johns...@gmail.com:
 Despire the
 coolness of Windows supporting time fields 64-bits wide for the least amount
 of pain it would probably be best if the time fields were left at 32-bits
 (although it would be really cool and forward thinking if we used 64-bits),

FWIW I'm in favor of 64 bit time fields, as the event horizon for
32-bit fields is only 27 years away. Even if you think that it's very
unlikely that any present day programs will still be used in 27 years,
you can think of this as enabling Unix timestamp calculations with
dates much further into the future than possible now.

Regards, Krzysztof
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: _wstat on Windows (actually stat stuff in general)

[Krzysztof Kosiński]

2011/9/26 Jernej Simončič jernej|s-gm...@eternallybored.org:
 But which is more likely to happen - user having a filename with foreign
 characters, or user having a symlink (which on Windows can only be created
 by administrators)...

Based on the bugs reported against Inkscape that were caused by this
kind of filename, I would say the former (foreign characters) is much
more common. A lot of users have English Windows but have a local
keyboard layout and name their documents in their local language (e.g.
Russian, Polish) which is not representable in latin1.

Regards, Krzysztof
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: _wstat on Windows (actually stat stuff in general)

[Krzysztof Kosiński]

2011/9/26 Kean Johnston kean.johns...@gmail.com:
 Plus I am
 fairly sure (but not 100%) that MBCS can represent all of the characters
 UTF-16 can (which is what the _wstat function uses).

MBCS is misleadingly named in Microsoft documentation. It is not
always a multibyte encoding. It is a locale-specific encoding that
depends on your localization of Windows and AFAIK is guaranteed to be
ASCII compatible, and in many cases it is actually a single-byte
encoding. On English Windows, this is cp1252 which is almost identical
to iso8859-1. On Polish Windows, this is cp1250. On Chinese Windows
it's probably gb18030. And so on. In many versions, MBCS can only
represent a little more than plain ASCII.

Funny characters (e.g. Unicode characters not representable in the
MBCS / locale encoding) are in fact rather common and cause tangible
bugs when using narrow Windows APIs (e.g. Inkscape opens all
drawings normally but this one won't open!), while it's rather hard to
pin down a case where the symlink problem you mention would affect the
user. The ordinary user is unlikely to create any symlinks, and I'm
not even sure that _wstat would be called when selecting the linked
file for opening in the file chooser.

Regards, Krzysztof
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: g_filename_to_uri() issue in glib-win32

[Krzysztof Kosiński]

2012/5/22 John Emmas john...@tiscali.co.uk:
 So for example, if the input string is Göran (encoded as UTF-8) I get the 
 wrong output (hopefully, you can see that the 'o' has an umlaut).  
 g_filename_to_uri encodes 6 characters and returns G%C3%B6ran instead of 
 encoding just 5 characters to return the correct URI string G%F6ran.

What you get is an URI encoding of the UTF-8 bytes. I think this is
the expected and correct behavior: there are multiple incompatible
locale encodings and there's no way for this function to know what
encoding you want to use for the URI. It would also fail if you had
characters not representable in the locale encoding.

This is at most a documentation bug. It should be stated that this
function converts the string byte-by-byte, and everything outside of
the 0-127 range is converted to hex escapes. (I think this is the only
sensible behavior for this function.)

Regards, Krzysztof
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: bugzilla cleanup

[Krzysztof Kosiński]

2013/2/4 Matthias Clasen matthias.cla...@gmail.com:
 Hi everybody,

 a while ago, we've talked about getting a handle on the enormous
 number of open bugs in glib and gtk.

This bug, which makes GOption useless on Windows and has accumulated
93 comments so far, could be easily fixed (it has patches) if someone
finally decided which way is preferable.
https://bugzilla.gnome.org/show_bug.cgi?id=522131

Regards, Krzysztof
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Stock Items Deprecation

[Krzysztof Kosiński]

2013/7/18 Emmanuele Bassi eba...@gmail.com:
 support for those features has already been developed and it is going
 to be added to GAction before we release GLib 2.38 and GTK 3.10, and
 improved in the future so that it matches with the overall spirit and
 design of the API. if you want to influence where the API is going,
 you can start looking at how to port your code, what you think it's
 missing, and file bugs. dropping on irc.gnome.org, in the #gtk+
 channel, is also a good idea.

OK, I guess that answers my question.

 you should *really* read the document linked in Jon's email; it
 answers the questions about when and where icons should be used inside
 menus. it's not a blanket removal (and it's not something done to
 emulate OSX; please, refrain from making snap judgements in the
 future).

I read the document before posting, and it did mention that icons are
OK for noun menu items. However, in your initial post you said
GAction replaces GtkAction; images on menus have been discouraged for
years...', and I was not aware that a replacement for the
presentation-related functionality of GtkAction will be added to
GAction - so this sounded like the ability to add icons to menu items
would be removed completely.

Regards, Krzysztof
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Stock Items Deprecation

[Krzysztof Kosiński]

2013/9/11 Emmanuele Bassi eba...@gmail.com:
 as the author of GtkRecentAction, I'm honestly not concerned.
 GtkRecentAction was a stop-gap that covered users of the old
 EggRecent* API, and was never really useful; in a sense, it was a
 class used to paper over a deprecation. shoving a bunch of recently
 used files with only the name and a 16 px MIME type icon as a
 differentiating feature in a menu (or in a toolbar menu button) always
 seemed to me like a very bad UI. the file selection widget has a
 better list of recently used files, these days.

The recently used files thing in the open dialog is utterly
confusing. It looks exactly like a directory listing, but the shown
files and directories are not actually in a single directory. The
first few times I encountered it, I thought there was some filesystem
disaster that mixed all my files together.

Maybe if the display was changed so that it did not resemble a
directory listing so much, it would be less confusing; but for now I
find this feature unusable.

Regards, Krzysztof
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Directional Images

[Krzysztof Kosiński]

2013/10/17 Jasper St. Pierre jstpie...@mecheye.net:
 I think the thing that we'd want is to have a separate RTL icon theme that
 inherits from the LTR icon theme, but overrides some icons with flipped
 icons. This can be done with a few tweaks to the icon-theme specification,
 and in GTK+.

I vaguely recall that once upon a time there were a few stock icons
with an -rtl suffix, which would be used instead of the normal icons
in an RTL environment.

This approach could be used with named icons too. When you request
some-icon in an RTL locale, the icon name resolver should first look
for icon-name-rtl, and if that doesn't exist in the theme, use
icon-name. I think this solution is both very simple and adequate.

Regards, Krzysztof
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Removal of icons in buttons/menus

[Krzysztof Kosiński]

2013/10/15 Ryan Lortie de...@desrt.ca:
   Any icon that comes before a menu item’s text should be laid out as
   if it is the beginning of the text...

 and

   In particular, icons of this sort should not go inside the margin...

 (...)

 GtkImageMenuItem puts its icon in the margin.  We don't ever want noun
 icons to appear here.

So this extremely ugly layout is actually *by design*?

That's very disappointing. I thought that displaying the menu icons in
this absurd place is actually an Ubuntu-specific bug in globalmenu,
and will eventually be fixed.

Regards, Krzysztof
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Heads-up: Potentially breaking changes to the GDK drawing model pushed

[Krzysztof Kosiński]

2014-06-21 3:00 GMT+02:00 Jasper St. Pierre jstpie...@mecheye.net:
 To better support Wayland with fewer copies and less drawing artifacts, I've
 pushed some potentially breaking changes to GDK, namely around
 gdk_cairo_create and gdk_window_begin_paint_region.

 https://git.gnome.org/browse/gtk+/commit/?id=d48adf9cee7e340acd7f8b9a5f9716695352b848
 https://git.gnome.org/browse/gtk+/commit/?id=be30e440c350f0f3e0f2572f7f3eab54ef96af0e

 With these changes, it is now illegal to call gdk_cairo_create outside of a
 begin_paint / end_paint. This was always sketchy, and would never work on
 Wayland anyway. If your code does this, we will print a warning and return a
 dummy surface which won't ever be composited back into the main surface.

This will also break the GTK 3 version of Inkscape, which paints its
canvas in an idle handler, and the draw signal only marks areas for
redraw. However, it may be fixable by using the begin_paint APIs.

Regards, Krzysztof
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Heads-up: Potentially breaking changes to the GDK drawing model pushed

[Krzysztof Kosiński]

2014-06-24 3:02 GMT+02:00 Jasper St. Pierre jstpie...@mecheye.net:
 May I ask why you can't paint in the draw signal? GDK already tracks
 invalidated windows marked by exposes and gdk_window_invalidate_rect itself.
 It should be as efficient as drawing in an idle handler, and also cooperates
 with the paint clock, where we can be synchronized to a compositor's redraw
 cycle.

If all drawing happens in the draw signal and the document has a lot
of demanding effects, e.g. SVG filters, it would completely kill
responsiveness of the UI. The idle handler solution also allows us
easily move drawing to a separate thread in the near future.

In general, the document displayed in Inkscape cannot be drawn in one
piece; it must be rendered as a series of strips that are shown on the
screen once they are ready. Otherwise it takes far too long.

Although I heavily rewrote the lower levels of Inkscape canvas (those
dealing with SVG objects) to use Cairo and generally cleaned it up,
the upper levels, dealing with editing controls and scheduling the
rendering, are still barely changed from the Sodipodi days. It is
certainly possible to do all drawing in a draw signal, for example by
submitting an invalidate request once a piece of the drawing has
finished rendering, but it will require a nontrivial amount of work.

Regards, Krzysztof
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Heads-up: Potentially breaking changes to the GDK drawing model pushed

[Krzysztof Kosiński]

 On Mon, Jun 23, 2014 at 9:59 PM, Paul Davis p...@linuxaudiosystems.com
 wrote:
 as Jasper noted in his reply, but i'll describe differently: it is one thing
 to draw (even in a separate thread) in a cairo surface that can later to
 used during an actual redraw. and certainly many programs have excellent
 reasons to do this to speed up redrawing. but this doesn't involving cairo
 drawing operations on the surface derived from a GdkWindow. you are drawing
 to an image surface that is basically just memory inside your process. you
 can do this from any thread, at any time.

I am aware of this difference, and Inkscape already renders to
intermediate memory surfaces rather than directly to the window in the
idle callback, but due to some legacy code it also draws the finished
surface to the window in the idle callback. What currently happens is:

- draw signal received
- queue exposed areas for rendering
- render in idle handler
- draw to window in idle handler

and, as far as I understand, what needs to happen is:

- draw signal received
- queue exposed areas for rendering
- render in separate thread
- invalidate part of the window corresponding to the completed rendering
- draw result to window in the draw signal handler

The only problem we have is that the part of the code that does the
above is very old (most of it is around 10 years old) and fairly
convoluted, so this change will require some effort.

Regards, Krzysztof
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: A Gtk's build system ?

[Krzysztof Kosiński]

2014-08-05 15:41 GMT+02:00 Bernhard Schuster schuster.bernh...@gmail.com:
 If this ever happens, I hope for waf to get some traction, it is way faster
 and has the power of py and also prevents all the version incompatibility
 issues on different host machines as one can ship the waf with the
 repository itself (or as a git submodule). Not to mention that it is very
 easy to extend and is well documented with plenty of examples. Enough adv.

I also support this. Waf is stupidly simple to use compared to
autotools, does not require silly lists of files to work, and things
such as generating a file from a script and then compiling it are much
easier to implement.

Regards, Krzysztof
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: A Gtk's build system ?

[Krzysztof Kosiński]

2014-08-06 21:43 GMT+02:00 Colomban Wendling lists@herbesfolles.org:
 Le 06/08/2014 21:30, Krzysztof Kosiński a écrit :
 [Waf] does not require silly lists of files to work

 If that refers to using globs in the build system files, don't.  Glob
 showed on many a situation to be the source of various build problems,
 including, but not limited to, a file to be missing from the source tree
 (which would not be easily noticeable and would work on the author's
 setup), or unexpected files to be included in a build.

I am not really convinced by this.

1. If there are any uncommitted files, version control will tell you about this.
2. If you have 'unexpected files' in the source tree, you are doing
something wrong.
3. Another common argument in favor of file lists is determining what
to include in the tarball. This is only an issue because by default
Autotools create a giant mess by putting generated files in the same
directories as the sources (CMake does this as well). Waf always puts
all generated files in a separate directory, so everything that's not
in the build directory should be distributed.

 Also, FWIW patterns can generally be used just fine in Autotools -- but
 again, please, don't use them.

Autotools can't correctly use patterns / wildcards, because it
requires manually re-running automake whenever a file is added or
deleted.
http://www.gnu.org/software/automake/manual/html_node/Wildcards.html
Waf stores a database of files seen on last build and therefore
doesn't suffer from this problem.

Regards, Krzysztof
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GTK+ 2.0.3 compat with previous 1.2.10

[Krzysztof Krzyzaniak]

On Sun, Jun 02, 2002 at 06:58:50PM +0100, Paulo J. Matos wrote:
 
 Hi all,
 
 I have GTK+ 1.2.10 installed, and I'm willing to update. I wish
 to know if I remove previous gtk+ version and install 2.0.3, will
 all apps using gtk+ 1.2.10 work with 2.0.3?

Simply answer: no.

  eloy
-- 
  Gwarancja cnoty -
To brak ochoty.

  (--) Jan Sztaudynger
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list

GDK Fonts

[Krzysztof Magrel]

How can I convert GdkFont * to char * font?
char * means XLFDs font. Function gdk_font_full_name_get doesnot exists (it
is deprecated also) in my gdk.
Thanks for any help

Krzysztof Magrel
Registered Linux User #157725

___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list

FW: GDK Fonts

[Krzysztof Magrel]

 How can I convert GdkFont * to char * font?
 char * means XLFDs font. Function gdk_font_full_name_get 
 doesnot exists (it
 is deprecated also) in my gdk.
 Thanks for any help
 
 Krzysztof Magrel
 Registered Linux User #157725

___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list

RE: Fonts

[Krzysztof Magrel]

I'm begginer in gtk, but now I know how  to do it. Below is function i wrote
to change fonts of elements. element is name of element (for example
button1), fontname is fontame in format -misc-*-8...*-iso8859-2, mw is
widget to window where is element (for example main window). It works to me.
I know it's lame, but I don't know another method

void ustaw_czcionke(char* element,char *fontname, GtkWidget *mw)
{
  GtkWidget *text;
  GtkStyle *style;
  GdkFont *font1;

  font1=gdk_font_load(fontname); //translate font to GdkFont*
  text = lookup_widget (mw, element);
  /* If no font is selected, or the font couldn't be loaded, just return. */
  if (!font1)
   {
fprintf(stderr,Bad font!\n);
return;
   }
  /* We copy the current style, and update the font. */
  style = gtk_style_copy (text-style);
  gdk_font_unref (style-font);
  style-font = font1;
  gdk_font_ref (font1);
  gtk_widget_set_style (text, style);
}

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]]On Behalf Of Sridhar Chigurupati
 Sent: Wednesday, July 10, 2002 12:53 PM
 To: [EMAIL PROTECTED]
 Subject: Fonts


 Hello,

 Can anybody please tell me the method for changing fonts and
 font size in GTK-1.2.

 Thanks in advance
 Sridhar


 ---R-E-K-L-A-M-A---
 Kolejna wiadomosc czeka na Ciebie pod adresem:
 http://www.bizz.pl/list_w_butelce_new/dostarczenie.php?id=1000


___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list

GDK Fonts

[Krzysztof Magrel]

How can I convert GdkFont * to char * font?
char * means XLFDs font. Function gdk_font_full_name_get doesnot exists (it
is deprecated also) in my gdk.
Thanks for any help

Krzysztof Magrel
Registered Linux User #157725

___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list

Maximize project

[Krzysztof Magrel]

How can I run my project (in gtk+) on full screen? It means I want to
maximize window of project. I can of course maximize it by heand after
application run. But I want my application do it itself on the start (of
course size of the window will depend of resolution (640x480,  800x600,
1024x768 etc.)). How function should I use ? Please help.

Krzysztof Magrel
Registered Linux User #157725

___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list

Where is glade2

[Krzysztof Magrel]

Where can I get glade2?

Krzysztof Magrel
Registered Linux User #157725
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list

How can I change color of fonts in GTK 1.2

[Krzysztof Magrel]

I've problem like in subject. Please help.

Krzysztof Magrel
Registered Linux User #157725
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list

RE: How can I change color of fonts in GTK 1.2

[Krzysztof Magrel]

 -Original Message-
 From: Jean-Michel OLTRA [mailto:[EMAIL PROTECTED]]
 Sent: Tuesday, July 30, 2002 9:02 PM
 To: Krzysztof Magrel
 Subject: Re: How can I change color of fonts in GTK 1.2


 On Tuesday 30 Jul 2002, Krzysztof Magrel wrote:
  It doesn't work for me :((

   Use sth like that ?
  
   GdkColor blanc = {65535, 65535, 65535};
   GtkWidget *label;
  
   label-style = gtk_style_copy(label-style);
   label-style-fg[GTK_STATE_NORMAL] = blanc;

 Aaargh !
 What do you want to do ? What kind of widget do you want to change the
I wanna change font's color of normal label (GtkLabel class)
 font color from ?

 Did you try to set colors in a rc-file ?
Yes, I already tried and every colors of fonts are now blue :) (I changed
entry fg[NORMAL] to #ff)
I don't know why Your solution doesn't work for me.
I've it like that:  GdkColor color;

  GtkWidget *label;

  color.red=65535;
  color.green=0;
  color.blue=0;

  label=lookup_widget(main_window,label8);
  label-style=gtk_style_copy(label-style);
  label-style-text[GTK_STATE_NORMAL]=color;


 --
 jean-michel

 --
 Zacznij dobrze dzien...  http://link.interia.pl/f162e



___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list

RE: How can I change color of fonts in GTK 1.2

[Krzysztof Magrel]

 -Original Message-
 From: Krzysztof Magrel [mailto:[EMAIL PROTECTED]]
 Sent: Wednesday, July 31, 2002 7:20 AM
 To: 'Jean-Michel OLTRA'
 Cc: '[EMAIL PROTECTED]'
 Subject: RE: How can I change color of fonts in GTK 1.2
 
 
 
 
  -Original Message-
  From: Jean-Michel OLTRA [mailto:[EMAIL PROTECTED]]
  Sent: Tuesday, July 30, 2002 9:02 PM
  To: Krzysztof Magrel
  Subject: Re: How can I change color of fonts in GTK 1.2
  
  
  On Tuesday 30 Jul 2002, Krzysztof Magrel wrote:
   It doesn't work for me :((
  
Use sth like that ?

GdkColor blanc = {65535, 65535, 65535};
GtkWidget *label;

label-style = gtk_style_copy(label-style);
label-style-fg[GTK_STATE_NORMAL] = blanc;
  
  Aaargh !
  What do you want to do ? What kind of widget do you want to 
 change the
 I wanna change font's color of normal label (GtkLabel class) 
  font color from ?
  
  Did you try to set colors in a rc-file ?
 Yes, I already tried and every colors of fonts are now blue 
 :) (I changed entry fg[NORMAL] to #ff)
 I don't know why Your solution doesn't work for me. 
 I've it like that:  GdkColor color;
 
   GtkWidget *label;
   
   color.red=65535;
   color.green=0;
   color.blue=0;
   
   label=lookup_widget(main_window,label8);
   label-style=gtk_style_copy(label-style);
   label-style-text[GTK_STATE_NORMAL]=color;
I of course tried also change it with:

 label-style-fg[GTK_STATE_NORMAL]=color;

without result
 
 
  -- 
  jean-michel
  
  
 --
  Zacznij dobrze dzien...  http://link.interia.pl/f162e
  
  
 
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list

2 (simple?) questions

[Krzysztof Magrel]

Hello everybody!

I have 2 questions. Perhaps someone knows solutions?

1. Is it possible to freeze display (and do something only in memory) and
unfreeze after program do what I want? I want to freeze main_window and in
this time I wanna show/hide widgets and add elements for lists etc. It takes
much more time (and looks not nice) when everytking is visible.

2. How can I change active widget? Tab key only can change coursor position
to the next widget. I want to change active widget from source level. (It
depends what user of program will do). I know that it is not possible for
some widgets (ie.labels, etc).

Did someone solve this problems?
Thanks

Krzysztof Magrel
Registered Linux User #157725

___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list

RE: 2 (simple?) questions

[Krzysztof Magrel]

  I have 2 questions. Perhaps someone knows solutions?

  1. Is it possible to freeze display (and do something only
 in memory) and
  unfreeze after program do what I want? I want to freeze
 main_window and in
  this time I wanna show/hide widgets and add elements for
 lists etc. It
  takes
  much more time (and looks not nice) when everytking is visible.

  2. How can I change active widget? Tab key only can change coursor
  position
  to the next widget. I want to change active widget from
 source level. (It
  depends what user of program will do). I know that it is
 not possible for
  some widgets (ie.labels, etc).

 For both of these questions you sould look in
 gtk+-2.0/gtk/gtkwidget.h in
 your include directory. There you should find answers. If you are not
 familiar with these files you can also take a look in the
 gtk+-2.0-reference manual
 at www.gtk.org.

I use gtk-1.2. I tried to find, but niether gtk_widget_grab_focus or
gtk_widget_activate doesnt work for me :(
And for 1st question i have no Idea :_(

Could someone help?

___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list

how to change a active widget ?

[Krzysztof Magrel]

How can I change active widget? Tab key only can change coursor position
to the next widget. I want to change active widget from source level. (It
depends what user of program will do). I know that it is not possible for
some widgets (ie.labels, etc).

Did someone solve this problems?
Can really nobody help me ?
Thanks


Krzysztof Magrel
Registered Linux User #157725
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list

RE: 2 (simple?) questions

[Krzysztof Magrel]

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
 Behalf Of [EMAIL PROTECTED]
 Sent: Tuesday, August 20, 2002 8:09 PM
 To: [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
 Subject: Re: 2 (simple?) questions


 Krzysztof Magrel wrote:
 2. How can I change active widget? Tab key only can change coursor
 position
 to the next widget. I want to change active widget from
 
 source level. (It
 
 depends what user of program will do). I know that it is
 
 not possible for
 
 some widgets (ie.labels, etc).
 
 
  I use gtk-1.2. I tried to find, but niether gtk_widget_grab_focus or
  gtk_widget_activate doesnt work for me :(
  And for 1st question i have no Idea :_(

 Hi, gtk_widget_grab_focus() works for me, what problem were
 you having
 with it?
I've got Segmentation Fault :_(
My function to change active widget looks like:

void
przejdz (char *element, GtkWidget * mw)
{
// Change active widget to widget with name element
  GtkWidget *w;
  if ((w = lookup_widget (mw, element)) == NULL)
return;
  gtk_widget_grab_focus (w);
  return;
}

and for example:

przejdz(entry3,main_window);

make 1 or 2 seconds without reaction (coursor doesn't) change it's position
(program freezes) and after this time window closes with Segmentation Fault
message.



 There are a bunch of freeze/thaw functions in gtk+-1.2, but
 they don't
 work very well and have all been removed for gtk2 (I think). gtk2 is
 much more sensible about painting the screen and you don't
 need this trick.

 John



 ==
 Fabric of Vision
 Dress and Drapery in Painting

 19 June - 8 September 2002

 For information and tickets:
 http://www.nationalgallery.org.uk/exhibitions/fabric/
 ___
 gtk-list mailing list
 [EMAIL PROTECTED]
 http://mail.gnome.org/mailman/listinfo/gtk-list

 Zgodz sie, co Ci szkodzi...  http://link.interia.pl/f163b



___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list

How to block alfanumeric entry

[Krzysztof Magrel]

I've GtkEntry in my program. I want sometimes allow to entry alfanumeric
signs, and sometimes I wanna entry only digits. How could I do it? I know
how to try what sign is press (event keypressed and event-keyval its the
sign). I thougth, that event-keyval=0 will enough, but not. I still see
every signs ;(  . What szhould I do ?


Krzysztof Magrel
Registered Linux User #157725

___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list

How don't let to change focus

[Krzysztof Magrel]

How can I don't let to change focus.
I wanna to stay in current widget (GtkEntry) until the good value isn't
proper.

How  can I do it ?

Krzysztof Magrel
Registered Linux User #157725

___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list

Block focus change

[Krzysztof Magrel]

How can I not let to change focus.
I wanna to stay in current widget (GtkEntry) until the good value isn't
proper.

How  can I do it ?

Krzysztof Magrel
Registered Linux User #157725

Krzysztof Magrel
Registered Linux User #157725

___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list

strange error

[Krzysztof Garus]

hello,

(Propably) normal call to gtk_label_set_text failed:


Program received signal SIGSEGV, Segmentation fault.
0x001fd401 in gtk_widget_queue_clear_area () from /usr/X11R6/lib/libgtk-1.2.so.0
(gdb) bt
#0  0x001fd401 in gtk_widget_queue_clear_area () from /usr/X11R6/lib/libgtk-1.2.so.0
#1  0x001fd65d in gtk_widget_queue_clear () from /usr/X11R6/lib/libgtk-1.2.so.0
#2  0x001fdf69 in gtk_widget_queue_resize () from /usr/X11R6/lib/libgtk-1.2.so.0
#3  0x001a9246 in gtk_label_set_text () from /usr/X11R6/lib/libgtk-1.2.so.0
#4  0x08069ca4 in rmInvocation (r=0x80f7b08) at remove.c:121
#5  0x005144c2 in RPMLremove (op=1, r=0x80f7b08, data=0x0) at rpm-system.c:329
#6  0x08052755 in on_btnRemove_clicked (button=0x80da9b0, user_data=0x0) at 
callbacks.c:306
#7  0x001b29db in gtk_marshal_NONE__NONE () from /usr/X11R6/lib/libgtk-1.2.so.0
#8  0x001d6648 in gtk_signal_remove_emission_hook () from 
/usr/X11R6/lib/libgtk-1.2.so.0
#9  0x001d5d6f in gtk_signal_set_funcs () from /usr/X11R6/lib/libgtk-1.2.so.0
#10 0x001d472a in gtk_signal_emit () from /usr/X11R6/lib/libgtk-1.2.so.0
#11 0x0015b1b0 in gtk_accel_group_activate () from /usr/X11R6/lib/libgtk-1.2.so.0
#12 0x0015b215 in gtk_accel_groups_activate () from /usr/X11R6/lib/libgtk-1.2.so.0
#13 0x002040df in gtk_window_set_default_size () from /usr/X11R6/lib/libgtk-1.2.so.0
#14 0x001b25c7 in gtk_marshal_BOOL__POINTER () from /usr/X11R6/lib/libgtk-1.2.so.0
#15 0x001d5dad in gtk_signal_set_funcs () from /usr/X11R6/lib/libgtk-1.2.so.0
#16 0x001d472a in gtk_signal_emit () from /usr/X11R6/lib/libgtk-1.2.so.0
#17 0x001fedec in gtk_widget_event () from /usr/X11R6/lib/libgtk-1.2.so.0
#18 0x001b2485 in gtk_propagate_event () from /usr/X11R6/lib/libgtk-1.2.so.0
#19 0x001b180e in gtk_main_do_event () from /usr/X11R6/lib/libgtk-1.2.so.0
#20 0x00231010 in gdk_wm_protocols_filter () from /usr/X11R6/lib/libgdk-1.2.so.0
#21 0x003907d6 in g_get_current_time () from /usr/lib/libglib-1.2.so.0
#22 0x00390de3 in g_get_current_time () from /usr/lib/libglib-1.2.so.0
#23 0x00390f8c in g_main_run () from /usr/lib/libglib-1.2.so.0
#24 0x001b1119 in gtk_main () from /usr/X11R6/lib/libgtk-1.2.so.0
#25 0x080689e1 in main (argc=2, argv=0xb864) at main.c:140
#26 0x003c27c6 in __libc_start_main () from /lib/libc.so.6
(gdb) frame 3
#3  0x001a9246 in gtk_label_set_text () from /usr/X11R6/lib/libgtk-1.2.so.0
(gdb) frame 4
#4  0x08069ca4 in rmInvocation (r=0x80f7b08) at remove.c:121
121 gtk_label_set_text(GTK_LABEL(r-lblQuestion), msg);
(gdb) list
116 msg = g_strdup_printf(_(Do you want to delete \%s\?),
117 directoryEnt(r-dir, r-namev[0])-name);
118 else
119 msg = g_strdup_printf(_(Do you want to delete %d entries?), 
r-namec);
120 
121 gtk_label_set_text(GTK_LABEL(r-lblQuestion), msg);
122 rmSetButtons(r, REMOVE_BTN_REMOVE|REMOVE_BTN_CANCEL, 
REMOVE_BTN_REMOVE);
123 g_free(msg);
124 }
125 
(gdb) p msg
$1 = 0x8112a08 Chcesz skasowa 2 pozycji?
(gdb) p *r-lblQuestion 
$2 = {object = {klass = 0x80ceb90, flags = 67560, ref_count = 2, object_data = 
0x80e5ec8}, private_flags = 0, 
  state = 0 '\000', saved_state = 0 '\000', name = 0x0, style = 0x80df2c0, requisition 
= {width = 47, 
height = 16}, allocation = {x = 4, y = 4, width = 259, height = 16}, window = 
0x8111b30, parent = 0x81108f0}
(gdb) p *r-lblQuestion-object-klass
$3 = {type = 42261, signals = 0x0, nsignals = 0, n_args = 4, construct_args = 0x0, 
  set_arg = 0x1a8f4c gtk_label_get_type+284, get_arg = 0x1a8fd8 
gtk_label_get_type+424, 
  shutdown = 0x201340 gtk_widget_get_default_visual+52, 
  destroy = 0x2013e4 gtk_widget_get_default_visual+216, finalize = 0x1a9364 
gtk_label_get+20}
(gdb)

window created, showed() but not showed

gtk+-1.2.10-3 with ThinIce theme (only colors, libthinice.so not found : )

bajcik
-- 
.- Krzysztof Garus - http://kolos.math.uni.lodz.pl/~bajcik/ --.
| http://kolos.math.uni.lodz.pl/~bajcik/duskc/ - prosz o krytyk :)  |
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list

Problems with fast timeouts

[Krzysztof Dubowik]

Hi,
  I wanted my timeout function to be called 200 times per second. Another words, my 
timeout function to be called every 5 miliseconds. However, when I mesured the 
intervals with gettimeofday I found out that the timeout function was called ca every 
20ms. My timeout function exectutes within 20microseconds. Is it a bug in GTK+ or am I 
doing something wrong? I use GTK+ 1.2.
  Please CC me when you reply to the list.
  Thanks in advance,
-- 
Krzysztof
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list

Re: Problems with fast timeouts

[Krzysztof Dubowik]

  [ i am assuming that you are working on linux, which might be a big
assumption. if not, then ignore all that i write here. ]
 
  you're using a multitasking, multiuser operating system with a
  scheduling granularity of 10ms. the kernel will to honor the 5ms
  request but will fail to provide it because it only inspects the timer
  queues 100 times a second. unless you build/use a kernel with HZ=1000,
  and/or use real-time scheduling, nothing can get you timing intervals
  of less than 10ms under linux. your 20ms timing interval is probably a
  reflection of average times.
 
  --p
 
 Even if you are using windows, you have a multitasking operating system
 with a 
 special interrupt every 10ms that selects the next thread.
 
 Karsten

I am poting my application from Windows MFC (where is does happily 5ms timeouts) to 
Linux. I would rather have my application to run on a standard kernel, so what's the 
solution? Where do I learn about realtime scheduling?

Regards,
-- 
Krzysztof
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list

Re: Problems with fast timeouts

[Krzysztof Dubowik]

  Hi,
   I wanted my timeout function to be called 200 times per second. 
Another words, my timeout function to be called every 5 miliseconds.
 
 why? what's the actual problem behind it?

It's a simulator of a measuring device where the sampling rate is fixed at 200Hz. I 
want to draw the graph at real-time - 1 pixel per 5ms.

BR,
-- 
Krzysztof
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list

Re: Problems with fast timeouts

[Krzysztof Dubowik]

Hi,
  Thanks for all your answers, you've been very helpful. I think I got the basic idea 
and I'll be able to carry on now.

 I do not know your background, Krisz, but this is pretty
 much a homework lesson done on realtime university courses.

I wish my university did realtime programming courses when I went there :-((( Maybe 
they do it now, but not when I was studying...

Regards,
-- 
Krzysztof
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list

Re: glib API for iterating the g_hash_table

[Krzysztof Garus]

On Wed, Jan 14, 2004 at 10:02:54PM +0800, Tony Yat-Tung Cheung wrote:
 Hi,
 
 Is there any API for iterating GHashTable?
 
 I only see the the g_hash_table_foreach() here. But sometimes people may
 like to iterate through a hash table and stop the iteration when certain
 conditions are met.
 
 Currently, there is g_hash_table_size(), we could easily add iteration
 by providing the following two new APIs,
 
 gconstpointer g_hash_table_get_key(GHashTable *hash_table, int pos);
 gconspointer g_hash_table_get_value(GHashTable *hash_table, int pos);
 
 The two APIs allows one to iterate the hash table, for example,
 
 for (i = 0; i  g_hash_table_size(hash_table); i++) {
  gconstpointer value = g_hash_table_get_value(hash_table, i);
 
  /* Do some processing here */
  if (is_match(value))
return TRUE;
 }
 
 Should we add the APIs?


I made something similar, but for GData:


typedef struct _GQDPair GQDPair;
struct _GQDPair
{
GQuarkquark;
gpointer  data;
};

GArray * g_datalist_pairs(GArray *a, GData **dl);

#define GQDq(qp, i) g_array_index(qp, GQDPair, i).quark
#define GQDd(qp, i) g_array_index(qp, GQDPair, i).data



/* GQuark/gpointer pairs from GDataList  */

void
on_keyval2GArray(GQuark key, gpointer *data, GArray *a)
{
GQDPair p;

p.quark = key;
p.data = data;
g_array_append_val(a, p);
}

GArray *
g_datalist_pairs(GArray *a, GData **dl)
{
if (a)
{
g_array_set_size(a, 0);
}
else
a = g_array_new(TRUE, FALSE, sizeof(GQDPair));

g_datalist_foreach(dl, (GDataForeachFunc)on_keyval2GArray, a);

return a;
}


bajcik
-- 
Krzysztof Garus [EMAIL PROTECTED]Linux User 171721
  Stronka: http://kolos.math.uni.lodz.pl/~bajcik/
  Polecam: http://kolos.math.uni.lodz.pl/~bajcik/duskc.html
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list

Re: New widgets and Glade

[Krzysztof Garus]

On Fri, Apr 30, 2004 at 12:00:17PM +0200, Diego Zuccato wrote:
 Hello all.
 
 Just a quick question: is it possible to use Glade2 when new widgets
 (from 2.4) are needed?

BTW, don't you think Glade should support plugins? Then
gtk-gl/gtkext/gtkwhatever - programmers would provide .xml files
describing custom widgets

bajcik
-- 
Krzysztof Garus [EMAIL PROTECTED]
  Stronka: http://kolos.math.uni.lodz.pl/~bajcik/
   Serwis: http://gielda.linux.pl/
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list

GOption patch for Windows

[Krzysztof Kosiński]

Hello

Can somebody look here:
http://bugzilla.gnome.org/show_bug.cgi?id=522131
and tell me whether this has a chance of being committed before GLib 2.20?
This is a fix for GOption on Windows, which actually makes it usable there.
Previously, GOption on Windows would fail on filenames which contain
characters not in the current codepage (e.g. Cyryllic characters in English
locale), which is a rather common occurrence, especially with people in
non-English countries using the English versions of Windows.

Without this patch GOption can't reasonably be used in cross-platform
applications, because on Windows some files which are accessible from other
apps will not open in apps using GOption.

Regards, Krzysztof Kosiński
-- 
View this message in context: 
http://www.nabble.com/GOption-patch-for-Windows-tp21747041p21747041.html
Sent from the Gtk+ - General mailing list archive at Nabble.com.

___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list

Re: [glib] malloc and bdwgc

[Krzysztof Kosiński]

On Jan 11, 2016 7:03 PM, "张海"  wrote:
>
> Yes, but the point of my previous email is that the third-party
GC_malloc() might eventually call malloc() itself, and by defining a
malloc() in my program, GC_malloc() will again call into my malloc() and
then GC_malloc() until stack overflow. Do you think this will happen?

One possible solution is to use something like libunwind to look at the
call stack. If your malloc detects it is called recursively, call
__libc_malloc instead of GC_malloc.

> Meanwhile since glib provides basic data structures for developers to
build their own data structure upon, and developers should be able to
decide which allocator their own data structure should use, I still think a
GMemVTable should be conceptually necessary. Is there anything that
prevents this from being implemented, for example with a
g_mem_vtable_init_hook() function? (Are weak symbols possible to be
portable? Or if not, missing such feature will still prevent many
applications from migrating to the new version of glib.)

It looks like almost nobody used this feature, and it had a performance
impact, so it was removed.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Invitation to connect on LinkedIn

[Krzysztof Klinikowski via LinkedIn]

LinkedIn





Krzysztof Klinikowski requested to add you as a connection on LinkedIn:
  
--

Benoit,

I'd like to add you to my professional network on LinkedIn.

- Krzysztof

Accept invitation from Krzysztof Klinikowski
http://www.linkedin.com/e/-w164j0-gsmyk5p1-2n/vwOBiyxfgiJSwN6Ctt8mDexxU95ZSV6nVZHx8Z/blk/I3118791288_2/1BpC5vrmRLoRZcjkkZt5YCpnlOt3RApnhMpmdzgmhxrSNBszYOnPwUcz4VdPwNcjd9bQ9hj6pJqQBibP4Qej4Md3cPczgLrCBxbOYWrSlI/EML_comm_afe/?hs=falsetok=2Ch-3LvVLgJQU1

View invitation from Krzysztof Klinikowski
http://www.linkedin.com/e/-w164j0-gsmyk5p1-2n/vwOBiyxfgiJSwN6Ctt8mDexxU95ZSV6nVZHx8Z/blk/I3118791288_2/39ve3wOcjATe34NcQALqnpPbOYWrSlI/svi/?hs=falsetok=1QL3Tv4ungJQU1
 
--

DID YOU KNOW LinkedIn can help you find the right service providers using 
recommendations from your trusted network? Using LinkedIn Services, you can 
take the risky guesswork out of selecting service providers by reading the 
recommendations of credible, trustworthy members of your network. 
http://www.linkedin.com/e/-w164j0-gsmyk5p1-2n/svp/inv-25/?hs=falsetok=200aUuG2XgJQU1
 
-- 
(c) 2011, LinkedIn Corporation___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

compile error in GNOME Builder 3.22.4 https://developer.gnome.org/gtk3/3.24/ch01s02.html

[Krzysztof Sadowski via gtk-devel-list]

build error in gtk with doc in Builder
it seems that I see the problem of the change I have made below


#include 

static void
print_hello (GtkWidget *widget,
 gpointer   data)
{
  g_print ("Hello World\n");
}

static void
activate (GtkApplication *app,
  gpointeruser_data)
{
  GtkWidget *window;
  GtkWidget *grid;
  GtkWidget *button;

  /* utwórz nowe okno i ustaw jego tytuł */
  window = gtk_application_window_new (app);
  gtk_window_set_title (GTK_WINDOW (window), "Window");
  gtk_container_set_border_width (GTK_CONTAINER (window), 10);

  /* Tutaj skonstruujemy kontener, który będzie pakował nasze guziki */
  grid = gtk_grid_new ();

  /* Zapakuj pojemnik w okno */
  gtk_container_add (GTK_CONTAINER (window), grid);

  button = gtk_button_new_with_label ("Button 1");
  g_signal_connect (button, "clicked", G_CALLBACK (print_hello), NULL);

  /* Umieść pierwszy przycisk w komórce siatki (0, 0) i wypełnij go
   * tylko 1 komórka poziomo i pionowo (tzn. bez rozpiętości)
   */
  gtk_grid_attach (GTK_GRID (grid), button, 0, 0, 1, 1);

  button = gtk_button_new_with_label ("Button 2");
  g_signal_connect (button, "clicked", G_CALLBACK (print_hello), NULL);

  /* Umieść drugi przycisk w komórce siatki (1, 0) i wypełnij go
   * tylko 1 komórka poziomo i pionowo (tzn. bez rozpiętości)
   */
  gtk_grid_attach (GTK_GRID (grid), button, 1, 0, 2, 1);

  button = gtk_button_new_with_label ("Quit");
  g_signal_connect_swapped (button, "clicked", G_CALLBACK
(gtk_widget_destroy), window);

  /* Umieść przycisk Zakończ w komórce siatki (0, 1) i ustaw go
   * rozpiętość 2 kolumn.
   */
  gtk_grid_attach (GTK_GRID (grid), button, 0, 1, 3, 1);

  /* Teraz, gdy skończyliśmy pakować nasze widżety, pokazujemy je wszystkie
   * za jednym zamachem, przez wywołanie gtk_widget_show_all () w oknie.
   * To wywołanie rekursywnie wywołuje gtk_widget_show () we wszystkich
widżetach
   * które są zawarte w oknie, bezpośrednio lub pośrednio.
   */
  gtk_widget_show_all (window);

}

int
main (intargc,
  char **argv)
{
  GtkApplication *app;
  int status;

  app = gtk_application_new ("org.gtk.example", G_APPLICATION_FLAGS_NONE);
  g_signal_connect (app, "activate", G_CALLBACK (activate), NULL);
  status = g_application_run (G_APPLICATION (app), argc, argv);
  g_object_unref (app);

  return status;
}

Krzysztof Sadowski
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list