About layouts
Hi ! I'm developing an app with gtk. I use glade for GUI development. My question is about the different kinds of layouts. I would like my app resizes by itself when a label text is really long. I've noticed I can do this by placing a table layout (I think vbox and hbox work well too). In fact, this behaves well even when changing fonts dpi (This is the answer to my question that you can see at http://mail.gnome.org/archives/gtk-app-devel-list/2006-January/msg00064.html ) But my app has a lot of labels and buttons so I estimated I need a lot of layouts creating a complex hierarchy (vbox inside a table layout, inside a hbox, inside a table layout again...) Did I forget a simply way to make this?? Thanks!! ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: About layouts
Fernando Apesteguía wrote: I'm developing an app with gtk. I use glade for GUI development. My question is about the different kinds of layouts. I would like my app resizes by itself when a label text is really long. I've noticed I can do this by placing a table layout (I think vbox and hbox work well too). In fact, this behaves well even when changing fonts dpi (This is the answer to my question that you can see at http://mail.gnome.org/archives/gtk-app-devel-list/2006-January/msg00064.html ) But my app has a lot of labels and buttons so I estimated I need a lot of layouts creating a complex hierarchy (vbox inside a table layout, inside a hbox, inside a table layout again...) Did I forget a simply way to make this?? Your question is not quite clear to me. It seems to be about two issues: 1. auto-resizing of labels, 2, what containers to use for your layout. Regarding GtkLabels: automatic resizing is their default behaviour, regardless of which sort of container (Gtktable, GtkVBox, etc.) it is being put into. Example: when working with Glade, just create an empty dialog window. Drop a new GtkLabel into it (directly into the window, without additional layout containers). Make the window as small as possible (not via the minimizie button). You will see that you can't make the window smaller than the dimensions needed by the GtkLabel to have its text (should be label1 or similar) fully visible. In Glade's properties window, when you type in additional text into the Label property of the GtkLabel, you can see the window grow as you type. Again, this is the default behaviour of GtkLabel (and most other types of widgets as well) and is not bound to particular containers like GtkTables or Boxes. However, if your texts may get really long, this behaviour shouldn't actually be what you want. Especially if the label has disabled its wrapping property, restricting the label text to just one line, the horizontal size requirement by the label may easily exceed the screen's dimensions, making the window wider than the screen as well. This would make your application basically useless. There are three common strategies to consider if you're planning to deal with display of really long texts. They aim at avoiding unrestricted size requests by the GtkLabel: 1. enable the wrap text property of the GtkLabel 2. put the GtkLabel into a GtkScrolledWindow 3. use GtkTextView instead of GtkLabel, with editable property unset. Regarding the other aspect of your question: what layout containers to use and the extent of complexity is determined solely by what layout you actually want to achieve. For instance, having 20 rows with each one consisting of a GtkButton and a GtkLabel next to it, and all widgets aligned vertically, is quite a simple layout. You would only need one GtkTable with 2 columns and 20 rows for it. You could also easily use 10 rows with 4 columns (button, label, button, label) each with the same single table. More complex layouts require additional layout containers, of course. You didn't provide any idea what sort of complex layout hierarchy you want to achieve so I can't give more detailed recommendations. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
About layouts
First of all, thanks for your suggestions. Actually my app. uses a static layout and the GtkLabels inside this, don't grown when the text becomes longer. The same GtkLabel behaves ok if it is inside a GtkTable. So I think I will change the static container. My app uses a menu bar and a GtkNotebook. In every tab, I have several GtkLabels and ProgressBars. So if I choose to use non-static containers I think I'll need two or three GtkTables for each tab.I have three tabs now but it is expected to have at least five. If I change the static layout + label for a deeper containers hierarchy (three levels for example)... will I have a lack of performance when loading the UI? Thanks in advance!!! -- Forwarded message -- From: Gus Koppel [EMAIL PROTECTED] Date: 14-feb-2006 14:30 Subject: Re: About layouts To: gtk-app-devel-list@gnome.org Fernando Apesteguía wrote: I'm developing an app with gtk. I use glade for GUI development. My question is about the different kinds of layouts. I would like my app resizes by itself when a label text is really long. I've noticed I can do this by placing a table layout (I think vbox and hbox work well too). In fact, this behaves well even when changing fonts dpi (This is the answer to my question that you can see at http://mail.gnome.org/archives/gtk-app-devel-list/2006-January/msg00064.html ) But my app has a lot of labels and buttons so I estimated I need a lot of layouts creating a complex hierarchy (vbox inside a table layout, inside a hbox, inside a table layout again...) Did I forget a simply way to make this?? Your question is not quite clear to me. It seems to be about two issues: 1. auto-resizing of labels, 2, what containers to use for your layout. Regarding GtkLabels: automatic resizing is their default behaviour, regardless of which sort of container (Gtktable, GtkVBox, etc.) it is being put into. Example: when working with Glade, just create an empty dialog window. Drop a new GtkLabel into it (directly into the window, without additional layout containers). Make the window as small as possible (not via the minimizie button). You will see that you can't make the window smaller than the dimensions needed by the GtkLabel to have its text (should be label1 or similar) fully visible. In Glade's properties window, when you type in additional text into the Label property of the GtkLabel, you can see the window grow as you type. Again, this is the default behaviour of GtkLabel (and most other types of widgets as well) and is not bound to particular containers like GtkTables or Boxes. However, if your texts may get really long, this behaviour shouldn't actually be what you want. Especially if the label has disabled its wrapping property, restricting the label text to just one line, the horizontal size requirement by the label may easily exceed the screen's dimensions, making the window wider than the screen as well. This would make your application basically useless. There are three common strategies to consider if you're planning to deal with display of really long texts. They aim at avoiding unrestricted size requests by the GtkLabel: 1. enable the wrap text property of the GtkLabel 2. put the GtkLabel into a GtkScrolledWindow 3. use GtkTextView instead of GtkLabel, with editable property unset. Regarding the other aspect of your question: what layout containers to use and the extent of complexity is determined solely by what layout you actually want to achieve. For instance, having 20 rows with each one consisting of a GtkButton and a GtkLabel next to it, and all widgets aligned vertically, is quite a simple layout. You would only need one GtkTable with 2 columns and 20 rows for it. You could also easily use 10 rows with 4 columns (button, label, button, label) each with the same single table. More complex layouts require additional layout containers, of course. You didn't provide any idea what sort of complex layout hierarchy you want to achieve so I can't give more detailed recommendations. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: About layouts
Fernando Apesteguía wrote: First of all, thanks for your suggestions. Actually my app. uses a static layout and the GtkLabels inside this, don't grown when the text becomes longer. The same GtkLabel behaves ok if it is inside a GtkTable. So I think I will change the static container. By static container you probably refer to a GtkFixed container? Yes, you should change that. GtkFixed (for static layout) should be considered pretty deprecated. Obviously a static layout container contradicts the concept of dynamic (re)layout. And the native concept of GTK+ GUI design and layout is highly dynamic. GtkFixed is mostly a courtesy for programmers from other GUIs, like the MS-Windows or QT ones, where static layout is the default and has a long history. Some of them tend to have problems getting used to more modern GUI layout and keep asking how do I specify X and Y coordinates of my buttons? To modern GUI layout processes, this question simply doesn't apply any more. Dynamic GUI design by using dynamic GTK+ containers is the modern way of flexible GUI design. This way, widgets don't have any sort of absolute X or Y coordinates nor static widths or heights. Instead, only the basic layout (their positions, sizes and optionally gaps relative to each other) are specified using layout containers. At runtime GTK+ then dynamically calculates the absolute positions and sizes of widgets within windows. This way also honors themability better than static layouts, since different themes may use different font sizes and hence require different dimensions for all sorts of texts. I think except when you're dealing with many bitmaps in a dialog and their pixel-wise layout is really important (which it usually isn't): don't use GtkFixed at all! My app uses a menu bar and a GtkNotebook. In every tab, I have several GtkLabels and ProgressBars. So if I choose to use non-static containers I think I'll need two or three GtkTables for each tab.I have three tabs now but it is expected to have at least five. If their layout is supposed to be aligned (as sketched in my previous posting) then you would need just one GtkTable for each tab. For more sophisticated layouts, more layout containers would be needed, indeed. If I change the static layout + label for a deeper containers hierarchy (three levels for example)... will I have a lack of performance when loading the UI? Basically: no. Generally, the number of widgets (including containers) is more important in terms of decreasing the performance than their layout and nesting is. On sub-GHz machines you should be on the safe side for numbers of up to about 200 widgets per dialog. However, yet there are two methods of loading the UI supported by Glade: 1. the UI definition is stored in an XML file and being loaded and parsed by libglade on each start of the application. 2. the UI definition is stored hardcoded, in binary form within the executable. There are a number of benefits and drawbacks of both of these ways. They have been subject of intense discussions already, and I don't want to repeat them here. Just this much: the libglade way is slower than the hardcoded way at execution time. On the other hand, at compilation time, the libglade way has no additional performance drawbacks, while especially for very complex UIs the hardcoded way may consume several extra minutes for every compiler run. The actual display speed is the same on both methods, just load times may vary. I should also note that the code output of Glade is planned to be removed in future versions, which some people (including me) regret. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: About layouts
Fernando Apesteguía wrote: First of all, thanks for your suggestions. Actually my app. uses a static layout and the GtkLabels inside this, don't grown when the text becomes longer. The same GtkLabel behaves ok if it is inside a GtkTable. So I think I will change the static container. Yeah, if you mean GtkFixed, abolish it. It should only be used for really special purposes, like maybe on a pocket computer with small fixed display size etc. Even then it is likely better to use other containers for windows that are not heavily packed with many widgets. My app uses a menu bar and a GtkNotebook. In every tab, I have several GtkLabels and ProgressBars. So if I choose to use non-static containers I think I'll need two or three GtkTables for each tab.I have three tabs now but it is expected to have at least five. If I change the static layout + label for a deeper containers hierarchy (three levels for example)... will I have a lack of performance when loading the UI? A little unrelated, but at work I use Java and over time I developed this policy: in GUI, prefer coding convenience over performance _nearly always_. (An exception might be e.g. a text area that displays a quickly growing log, like +30 lines per second, there you might need to pay special care to performance.) In your case, performance is less important yet, since you have the dynamic/static layout alternative in the first place. And I assume GtkFixed is not quite convenient too work with either. So, screw performance, there are more important things at stake ;) And actually, performance won't even suffer considerably. So, switch to dynamic layout, it's by far better in nearly all respects and only marginally worse in the others. Paul ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GtkTreeView get selected row AND column
Hi list! I have a GtkTreeView and what I want to do is when the user is over an editable cell, the editing begins automatically without having to press enter. And the other thing that i want to do is that when the user is over a cell on a certain column the cursor changes automatically to the next (he cant edit that cell). The GtkTreeView is a ticket editor, when the user is on the first column, the editing should be started automatically so he puts a product code, then when he press enter, the second column is filled with the description of the product wich has that code and the third column should get the focus, where, again without having to press enter, he inputs the amount and then it jumps to the first column on the next row. This is why i need to know the row and column, so in the cursor_changed signal i can decide to emmit start_editing or to pass the focus some where else. If is any other way to do it, please! :D Thanks all. Saludos, Juan Pablo. ___ A tu celular ¿no le falta algo? Usá Yahoo! Messenger y Correo Yahoo! en tu teléfono celular. Más información en http://movil.yahoo.com.ar ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkTreeView get selected row AND column
Juan Pablo wrote:
Hi list!
I have a GtkTreeView and what I want to do is when the user is over an
editable cell, the editing begins automatically without having to press
enter. And the other thing that i want to do is that when the user is
over a cell on a certain column the cursor changes automatically to the
next (he cant edit that cell).
The GtkTreeView is a ticket editor, when the user is on the first
column, the editing should be started automatically so he puts a product
code, then when he press enter, the second column is filled with the
description of the product wich has that code and the third column
should get the focus, where, again without having to press enter, he
inputs the amount and then it jumps to the first column on the next row.
This is why i need to know the row and column, so in the cursor_changed
signal i can decide to emmit start_editing or to pass the focus some
where else.
you can use gtk_tree_view_set_cursor() and gtk_tree_view_get_cursor().
I store the row number in my model for easy reference.
GtkTreePath *path;
GtkTreeViewColumn *column;
glong column_ix,row_ix;
gtk_tree_view_get_cursor(treeview,path,column);
if(path column) {
GtkTreeIter iter;
if(gtk_tree_model_get_iter(treestore),iter,path)) {
GList *columns=gtk_tree_view_get_columns(treeview);
column_ix=g_list_index(columns,(gpointer)column)-1;
g_list_free(columns);
gtk_tree_model_get(treestore,iter,TABLE_POS,row_ix,-1);
}
}
if(path) gtk_tree_path_free(path);
printf(cursor at col/row = %d,%d\n,column_ix,row_ix);
If is any other way to do it, please! :D
Thanks all.
Saludos, Juan Pablo.
___
A tu celular ¿no le falta algo?
Usá Yahoo! Messenger y Correo Yahoo! en tu teléfono celular.
Más información en http://movil.yahoo.com.ar
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
gtk + ALP
hi, I recently stumbled upon: http://www.linuxdevices.com/news/NS4663700447.html which outlines the ALP platform. A GTK+/gstreamer stack is included in it and I see no X server. I assume this means that they plan to either port GTK+ to this platform's low-level APIs or use an existing technology such a DFB and GTK+/DFB. Is there someone who has heard about this and who would be allowed to confirm my guesses ? regards, Mathieu -- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GTK+ team irc meeting
The meeting is intended for the GTK+ team, but everybody is welcome to come and listen. The meeting logs will be posted on the GTK+ website (http://www.gtk.org/plan/meetings). Place: irc.gnome.org:#gtk-devel Time: 21:00 UTC (16:00 EST), Tue, Feb 14 Possible agenda items: - async file chooser branch - rich text transfer api Matthias ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
RE: Rich Text copy and paste (bug #324177)
On the Windows platform (as an example), there are standards for richtext interchange between applications. Those standards are RTF and to a lesser (but growing) extent, (X)HTML. You'll find that a lot of the more richtext copy+paste centric apps on Linux and MacOS also commonly use these interchange formats. Applications like MSIE, Outlook, Office, Mozilla, Evolution, AbiWord, etc. will offer their selections in these formats and copy+paste between them can be said to work fairly well. These are applications that know how to serialize and deserialize their data Model. If these applications encounter some semantic that their data Model can't handle, they have already assumed responsiblity of the data and will fall-back or transform that data as is necessary. The Model will never be in a state that is inconsistent with what its View or Controller can respresent. In his simple MUA example, Mitch proposes that perhaps there is a class of applications where the Model and View are considerably smarter than the Controller. GtkTextView is pretty smart, I'll grant you, but all of its data must have come from somewhere. The application feeding the TextView data must have a mapping from that data's model into the TextView's model. And the inverse must be true for deserialization. Consider the primary ways that a user will get data into a MUA: 1) Typing it herself, interacting with the MUA's controls 2) Displaying a previously sent email (either by itself, or in a reply-to form). This email may have come from a smarter MUA, and thus need to be dumbed-down for viewing or editing. 3) A distant third is pasting between MUA message windows. Since the data came from another window in your application, it is probably safe to assume that this data is already in a format that your MUA understands. I contend that this shows that Mitch's example MUA would necessarily be smart enough to filter out the bits of HTML it doesn't understand for viewing. It must also be smart enough to serialize the TextView into a HTML syntax that it does understand when sending. It's not hard to make the leap from serializing all of a message when you click Send to serializing a subset of the message when you hit copy. Similarly for recieve vs. paste. In these cases, the MUA doesn't need (or even want) the TextView to do anything on behalf of it. Applications should not blindly use GtkTextView blindly as both their Model and their View. Any app that does this probably deserves whatever wonky results they get. Mitch's tagset attempts to strike a middle-ground, but I don't think that a middle ground is what we should seek. The tagset attempts to brute-force filter some semantics that aren't handled by an application. Think I don't support bold text. But it can't handle more complex scenarios, such as I don't handle tables inside of tables or I handle bold text and italic text, but not bold, italic text. But filtering may not be what you want. One might want to tranform a HTML table into an ASCII-art one, or a bullet/numbered list into asterisks/numbers plus some tabs. The tagset as proposed can't capture even these simple semantics. In doing so, it proposes to use yet another interchange format that is specific to GtkTextView. Unless more common formats are offered AND accepted or a clipboard manager does conversion, copying and pasting richtext between applications is in the same sorry state that it is today. This is especially true for inter-toolkit cases. I can't see a tagset-based approach working for anything but the most contrived examples. And I don't see that as preferable (or even easier) than having the application filtering the data itself as it must already be doing elsewhere. With that said, I think that the best course of action is to keep this sort of application-style logic out of the TextView, and push the onus onto the apps that would use it. My ideal setup would probably be: *) The TextView can serialize and deserialize (a selection of) itself into UTF-8 text, for the common copy + paste semantic. *) Applications are responsible for serializing and deserializing the text view into more complex formats, such as RTF and XHTML. Push any smarts up to the application level rather than the widget level, since the application should have control over its Model, and not the other way around. *) If it is felt to be necessary (and I'm not convinced that it is), there can be an opt-in serialization/deserialization API for several of these more-common interchange formats, such as XHTML and RTF. These must be optional, since they mustn't compete with their parent applications for control of the interchange atoms on the clipboard. Best, Dom -- Counting bodies like sheep to the rhythm of the war drums. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
RE: gtk + ALP
Hi everyone, Wow, you don't waste any time, I just saw the press release myself! Anyways, I am one of the architects for this new framework. I've been lurking on this list for a little while now, and I can try to answer some of your questions. Some things are probably confidential, but I'll be as open as I can about everything else. Obligatory disclaimer: Please note that I am *not* an official PalmSource spokesperson, so please don't expect that. If I start getting quoted in the press or anything, someone might tell me to stop talking. As for whether MAX will run on X or Direct FB, I believe the internal debate continues. :-) We're investigating both, and see some advantages on either side. Many folks seem to be assuming that it will not run on X, mostly due to performance concerns, but I haven't seen the numbers from the people investigating that. Also, the demo at 3GSM *does* run on X, for what that's worth. I'd be curious to hear what you folks think about the matter. As an aside, the press release said an optimized implementation of GTK+, but we don't really know what optimized means yet. We've mostly been running GTK on desktop machines while the X DFB folks do their various investigations. For my part, I'd really like to participate in the GTK+ development community, and to do this with its support. My own goals are to make sure that anything we build on top of GTK+ is done in a manner that is consistent with it, and that any modifications we make are able to be accepted into the official distribution (see optimized above). One thing I would like to know is what you folks think of all this, and whether you are interested in making GTK+ the basis of a handheld applications platform. That's certainly our plan, but some changes might be necessary to get it working well on a handheld, and I don't know if you would be interested in taking them unless they were really needed on the desktop as well. I'd certainly like to work in harmony with the main distribution, but we could also consider working with a separate project like GPE if you are really focused on the desktop. I should probably also warn you that our schedule is quite short, and that may limit the degree of our cooperation at times. We'll do the best we can, though. In case you're wondering about me, I'm a software engineer living in California in the US. I've been working on various flavors of Palm OS for nearly 8 years now, and have always loved working on frameworks best. That said, I am new to GTK+, and have relatively little experience on Linux as well (I'm a long time Mac guy). So if I seem naïve, please don't assume that I'm stupid, and feel free to help educate me if you are so inclined. :-) Regards, Jesse -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mathieu Lacage Sent: Tuesday, February 14, 2006 3:32 AM To: gtk Subject: gtk + ALP hi, I recently stumbled upon: http://www.linuxdevices.com/news/NS4663700447.html which outlines the ALP platform. A GTK+/gstreamer stack is included in it and I see no X server. I assume this means that they plan to either port GTK+ to this platform's low-level APIs or use an existing technology such a DFB and GTK+/DFB. Is there someone who has heard about this and who would be allowed to confirm my guesses ? regards, Mathieu -- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Rich Text copy and paste (bug #324177)
On 2/14/06, Dominic Lachowicz [EMAIL PROTECTED] wrote: With that said, I think that the best course of action is to keep this sort of application-style logic out of the TextView, and push the onus onto the apps that would use it. My ideal setup would probably be: *) The TextView can serialize and deserialize (a selection of) itself into UTF-8 text, for the common copy + paste semantic. Sure, it does that already. *) Applications are responsible for serializing and deserializing the text view into more complex formats, such as RTF and XHTML. Push any smarts up to the application level rather than the widget level, since the application should have control over its Model, and not the other way around. This is what mitch's gtk_rich_text_register() api does, more or less: it gives apps a way to register functions for serializing and deserializing text buffer content into different formats. *) If it is felt to be necessary (and I'm not convinced that it is), there can be an opt-in serialization/deserialization API for several of these more-common interchange formats, such as XHTML and RTF. These must be optional, since they mustn't compete with their parent applications for control of the interchange atoms on the clipboard. mitch's current patch just provides an internal format, but I think we would be happy to include XHTML and RTF format support if patches appear... So, it seems your recommendations are fairly close to what mitch's patch already provides. Or did I miss your critcism of the tagset mechanism somehow ? Matthias ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Rich Text copy and paste (bug #324177)
Hi Matthias, *) The TextView can serialize and deserialize (a selection of) itself into UTF-8 text, for the common copy + paste semantic. Sure, it does that already. Yup, I'm fully aware. *) Applications are responsible for serializing and deserializing the text view into more complex formats, such as RTF and XHTML. Push any smarts up to the application level rather than the widget level, since the application should have control over its Model, and not the other way around. This is what mitch's gtk_rich_text_register() api does, more or less: it gives apps a way to register functions for serializing and deserializing text buffer content into different formats. If that's all it did, I wouldn't have a problem with it. *) If it is felt to be necessary (and I'm not convinced that it is), there can be an opt-in serialization/deserialization API for several of these more-common interchange formats, such as XHTML and RTF. These must be optional, since they mustn't compete with their parent applications for control of the interchange atoms on the clipboard. mitch's current patch just provides an internal format, but I think we would be happy to include XHTML and RTF format support if patches appear... So, it seems your recommendations are fairly close to what mitch's patch already provides. Or did I miss your critcism of the tagset mechanism somehow ? I think that you missed my point completely. So let me restate it, hopefully more clearly: *) I think that Mitch's data model incompatibility problem is a very real one that needs to be addressed. *) I think that the tagset metaphor is too primitive to do anything genuinely useful with and we will be butting our heads up against that wall *very* quickly. *) Richtext copy + paste should be handled *only and entirely* by the app that owns the GtkTextView, and not the GtkTextView itself, because only the application necessarily knows what its data model can represent. Combine this with the limitations evidenced by my previous point to get the full effect. The fact that some applications might use GtkTextView as both their Model and View is confusing the situation. The app and only the app needs to have fine control over what goes into the Model. It - not the GtkTextView - is the Controller. This should be solely the application's responsibility, and not part of the GtkTextView API. *) I think that if we want to provide convenience functions for serializing/deserializing common formats, then that's great. But I don't think it is necessary, nor do I think that a subsetting/translation mechanism such as the one that Mitch proposes has any business being anywhere near the serialization API or GtkTextView. *) I think that tagsets are the wrong approach for solving this problem. As such, I think that richtext copy+paste facilities should be something layered on top of the GtkTextView by the parent application and not be a builtin feature of the TextView itself. The application knows in detail what its data model and controller supports. The TextView does not, and should remain dumb in this regard. Best, -- Counting bodies like sheep to the rhythm of the war drums. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Rich Text copy and paste (bug #324177)
On 2/14/06, Dominic Lachowicz [EMAIL PROTECTED] wrote: I think that you missed my point completely. So let me restate it, hopefully more clearly: Ok, thanks for being patient :-) I think I understand better now. You saying we should just make the list of readable and writable formats of a TextView extensible (by registering serialization/deserialization functions) and maybe have a couple of predefined formats for which GTK+ ships serialization functions. And remove all the tagset stuff... Is that accurate ? Matthias ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Rich Text copy and paste (bug #324177)
*) I think that the tagset metaphor is too primitive to do anything genuinely useful with and we will be butting our heads up against that wall *very* quickly. *) Richtext copy + paste should be handled *only and entirely* by the app that owns the GtkTextView, and not the GtkTextView itself, because only the application necessarily knows what its data model can represent. Combine this with the limitations evidenced by my previous point to get the full effect. I think You are not entirely right. You can very well _export_ richt text data from the GtkTextView into RTF (or XHTML) without the need for the application to interfere (since you don't have to have any styles or more sophisticated features). Of course, you should be able to let the application override this... P.T. -- Petr Tomasek http://www.etf.cuni.cz/~tomasek ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
