Re: Using GTK in proprietary software
Il giorno ven, 15/02/2019 alle 10.26 +0100, Jean-Dominique Frattini ha scritto: > And what if the final program is statically linked with Gtk+ (ie on Windows > with mingw32) ? Citing https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic: "If you statically link against an LGPLed library, you must also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application." On the technical side I heard someone successfully used static linking with GTK+ but I personally never see such an application. I do not use windows though. Ciao. -- Nicola ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Using GTK in proprietary software
Il giorno ven, 08/02/2019 alle 18.45 +, asrs ha scritto: > Dear Nicola, > > Thankyou for your informative response, > I would like to know if I may use "GTK" as a suffix in the name of my > commercial product. There already are plenty of applications with GTK in their names, see e.g.: https://www.linux-apps.com/search/projectSearchText/gtk All that said, IANAL. Anyway I really doubt you will find a name not already picked up by some project and IMO this is just bikeshedding. Ciao. -- Nicola ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Using GTK in proprietary software
Il giorno mer, 06/02/2019 alle 16.25 +, asrs via gtk-app-devel-list ha scritto: > Dear GTK developers, > > I want to redistrbute GTK (and its LGPL) unabridged with proprietary software, > to make a graphical application. Ciao, if you use shared linking (AFAIK the only way officially supported) you wont have any problem. Of course you must still comply with the other terms, e.g. you cannot sneakily modify the GTK+ source code: https://gitlab.gnome.org/GNOME/gtk/blob/master/COPYING > Additionally my program will make calls to routines in GTK objects, > ... I do not understand the question: is there any other reason one should link to a library? Ciao. -- Nicola ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Fixing the GtkTreeModel::row-deleted inconsistency
On Tuesday 15 May 2007 10:37, Kristian Rietveld wrote:
It depends what you mean with remove the row from the model. If that
means unlinking the row from the model's data structures, then there's
not a nice way anymore to retrieve an iterator to access that row. And
if _get_iter() is still supposed to be working, all other model methods
should also work: you are much better off not removing the row in that
case :)
Yes, I meant unlink it from the model. Think about something like this:
gboolean
gtk_list_store_remove (GtkListStore *list_store,
GtkTreeIter *iter)
{
GtkTreePath *path;
GtkSequencePtr ptr, next;
g_return_val_if_fail (GTK_IS_LIST_STORE (list_store), FALSE);
g_return_val_if_fail (VALID_ITER (iter, list_store), FALSE);
path = gtk_list_store_get_path (GTK_TREE_MODEL (list_store), iter);
ptr = iter-user_data;
next = _gtk_sequence_ptr_next (ptr);
- _gtk_tree_data_list_free (_gtk_sequence_ptr_get_data (ptr),
list_store-column_headers);
+ list_store-removed_data = (GtkTreeDataList *) _gtk_sequence_ptr_get_data
(ptr);
_gtk_sequence_remove (iter-user_data);
list_store-length--;
gtk_tree_model_row_deleted (GTK_TREE_MODEL (list_store), path);
+ _gtk_tree_data_list_free (list_store-removed_data,
list_store-column_headers);
+ list_store-removed_data = NULL;
gtk_tree_path_free (path);
if (_gtk_sequence_ptr_is_end (next))
{
iter-stamp = 0;
return FALSE;
}
else
{
iter-stamp = list_store-stamp;
iter-user_data = next;
return TRUE;
}
}
/* This new API method gets values from the very last deleted row: no needs
for an iter arg */
void
gtk_list_store_get_removed_value (GtkListStore *list_store,
gint column,
GValue *value)
{
GtkTreeDataList *list;
g_return_if_fail (GTK_IS_LIST_STORE (list_store));
g_return_if_fail (column list_store-n_columns);
g_return_if_fail (list_store-removed_data != NULL);
list = list_store-removed_data;
while (tmp_column-- 0 list)
list = list-next;
if (list == NULL)
g_value_init (value, list_store-column_headers[column]);
else
_gtk_tree_data_list_node_to_value (list,
list_store-column_headers[column],
value);
}
Of course, this solution needs a private field in the _GtkTreeStore struct and
a new API function, but it does not break anything and provides what needed.
Anyway, I think moving gtk_tree_model_row_deleted() at the top is a better
solution, but if you want backward compatibility, well, what can you do?
I think row-deleted does specifiy you the subject, one of its arguments
is the path ...
Yes, but if I need some data from the model I must duplicate it.
I don't want to bother, I only want to highlight that the row-deleted signal
(from an application developer's point of view) is, at this moment, quite
useless. But maybe I'm short in fantasy ...
-- Nicola
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: serial ports
On Monday 14 May 2007 20:49, Pavel A. da Mek wrote: When I want to use serial ports, shall I write separate code for Windows and for Linux, or is there some library function which would allow to do it in the platform independent way? I hit the same problem in 2004, and I wrote an abstraction layer and 2 different implementations. Basically, I implemented open(), close(), read() and write() using termios.h in linux and the Windows API (CreateFile(), ReadFile(), WriteFile() ...) in windows. read() and write() are implemented in a blocking way, because I'm used to put all the dialing stuff in a separate thread. If you want, I can send you the relevant code: be carefull, it is a beautiful example of bad C C++ mixing. -- Nicola ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Catching the row deleted from a GtkTreeModel implementation
I'm keeping some summary fields of a GtkListStore and I need to update them on every model change. The problem is while catching the row-deleted signal the row is yet deleted, so I can't access the row content to update my summary fields. How can I do it? Thanks, -- Nicola ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Catching the row deleted from a GtkTreeModel implementation
On Friday 09 February 2007 11:39, Suma H.S wrote: how r u deleting the row? It should be either through some key-press or mouse-click, in either case u must select the row before selecting. So...If it is through a key-press, catch the key-press signal and if it is through a mouse-click, catch mouse-click signal and access the selected row. Now do all the updations u want and then delete the row from the model. The model management is inside a library and it is shared by more applications. Of course I can provide a function to call before a delete operation, but I am short in memory and I'm sure before or after to forget to call this function in the application. -- Nicola ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Catching the row deleted from a GtkTreeModel implementation
On Friday 09 February 2007 11:55, Vivien Malerba wrote: I would suggest a different approach: add your own column to the GtkListStore which stores your information summary as a GObject (so you know when that object is destroyed). This approach seems quite complex but yes, it makes the job. Maybe I'll try to use a custom G_TYPE_BOXED instead of a GObject to improve performances, but the concept is the same. Thank you for your suggestion, -- Nicola ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GObject extension propose (GContainer)
Hi all, I'm a GObject based libraries (for UI purpose and not) user and I often need a generic container to derive my own types. In my opinion, I think this generic container must be included inside the GObject library ... it could be used by a lot of derived libraries providing a common approach. I published my solution - that is, what I am currently using - on sourceforge. http://sourceforge.net/projects/gcontainer/ Is it a good idea? Is something planned in this direction? Am I totally wrong? I need feedbacks ... Nicola ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
